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PREFACE 


MANUAL OBJECTIVES 


The goal of this manual is to provide information necessary to prepare 
a conventional I/O driver for RSX-11M and subsequently incorporate it 
into an operational user-tailored system. A "conventional" driver is 


best explained by example. Disks and unit record devices are 
considered conventional; the LPS-11, UDC-1ll, and TMll are considered 
unconventional. Complexity of device servicing requirements sets the 


dividing line, which is not easily established in black-and-white 
terms. 


INTENDED AUDIENCE 


The manual assumes that you understand the device for which you are 
writing a driver, and that you are familiar with the PDP-1l processor, 
its peripheral devices, and the software supplied with an RSX-11M 
system. Although this manual is organized tutorially, the intended 
audience is assumed to be at a system programmer level of expertise; 
thus, the manual does not contain definitions of data processing terms 
and concepts familiar to senior-level professionals. 


STRUCTURE OF THIS DOCUMENT 


This document proceeds from chapter to chapter toward increasingly 
detailed levels of implementation. 


Chapter 1 is a general introduction to I/0 drivers in the RSX-11M 
system. 


Chapter 2 is a functional description of the RSX-11M device-level I/C 
system. It discusses both data structure and code requirements. 


Chapter 3 details how to incorporate a user-written driver into the 
system. 


Together, Chapters 1, 2, and 3 provide a complete description of the 
requirements that must be met in creating a system that contains a 
user-written driver. 


Chapter 4 provides programming-level details on I/O data _ structures 
and on drivers that service several controllers. 


Chapter 5 discusses all the I/O-related Executive services. 
Chapter 6 gives two examples of user-written drivers. 


Appendix A describes the address doubleword. 


vii 


Appendix B outlines special considerations for extended memory NPR 
device drivers. 


Appendix C lists system macros that supply symbolic offsets for system 
data structures. 


Appendix Dis a guide for the user in developing an Ancillary Control 
Processor (ACP). 


ASSOCIATED DOCUMENTS 


Familiarity with the system implies an in-depth exposure to the 
following manuals: 


e RSX-11M System Generation and Installation Guide 


@e RSX-11M/M-PLUS I/O Drivers Reference Manual 


e RSX-11M/M-PLUS Executive Reference Manual 
e RSX-11M/M-PLUS Utilities Manual 


e IAS/RSX-11 I/O Operations Reference Manual 
As adjuncts to this manual, you are advised to study existing I/0 
drivers. The RL-11 disk driver is a good example of an NPR device and 
the TA-11 (cassette) is illustrative of a programmed I/O device. In 
addition, a perusal of Executive source code contained in the files 
IOSUB, SYSXT, DRQIO, BFCTL, and DRDSP (stored in UFD [11,10] on the 
Executive source disk) is recommended. 


Other manuals closely allied to the purposes of this document are 
described briefly in the RSX-11M/RSX-11S Information Directory and 
Index. The Information Directory defines the intended readership of 
each manual in the RSX-11M/RSX-11S set and provides a brief synopsis 
of each manual's contents. 
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SUMMARY OF TECHNICAL CHANGES 


This revision of the RSX-11M Guide to Writing an I/0 £Driver 
incorporates the following technical changes and additions: 


ae 


Tables have been added to aid the user in establishing 1/0 
function bit masks for disk drives, magtape drives, and unit 
record devices (see Tables 4-3, 4-4, and 4-5). 


Error logging offsets have been added to the SCB and_ UCB. 
See the descriptions of the SCB and the UCB in Chapter 4. 


Other additions have been made to various UCB offsets: 


e New symbolic name U.MUP has been added (redefinition of 
U.CLI; see Chapter 4). 


e Symbolic names for magtape density bit masks have been 
added to the description of U.CW3 (see Chapter 4). 


e The DV.MBC offset to U.CWl has been renamed to DV.EXT (see 
Chapter 4). 


Some Executive routines listed in Chapter 5 have been moved 
to new Executive modules. The following is a list of the 
affected modules and subroutines: 


Routine Old Module New Module 
SACHKB/SACHCK TOSUB EXESB 
SASUMR IOSUB MEMAP 
SDEUMR IOSUB MEMAP 
SDVMSG IOSUB EXESB 
SMPUBM IOSUB MEMAP 
SMPUB1 IOSUB MEMAP 
SRELOC IOSUB MEMAP 
SSTMAP IOS UB MEMAP 
SSTMP1 IOSUB MEMAP 


In addition, the inputs to SMPUB1 have been modified (see 
Chapter 5). 


Three additional routines have been documented in Chapter 5: 
SEXRQP, SQRMVF, and SSWSTK. 


An appendix intended to aid the user in writing an Ancillary 
Control Processor (ACP) has been added (see Appendix D). 
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CHAPTER 1 


INTRODUCTION TO I/O DRIVERS 


The software supplied by DIGITAL for an RSX-11M system includes I/0 
drivers for a number of standard I/O devices. An I/O driver is a part 
of the RSX-11M Executive that services one type of I/0 device. A 
driver may handle one or several controllers, each with one or several 
device-units attached. 


1.1 RESIDENT AND LOADABLE DRIVERS 


A driver can be resident or loadable. A resident driver is a 
permanent part of the Executive, incorporated at system generation. A 
loadable driver, while also part of the Executive, can be added to or 
unloaded from a system almost at will by means of MCR or VMR commands. 
During the system generation dialog, you can specify that you want 
this facility: 


Making drivers loadable can result in less Executive code, and _ thus 
permits an increase in available dynamic storage region (pool) space 
or increased space for user tasks. You can unload from the system any 
driver that is not needed for a period of time. For example, assume 
your system has both a paper tape reader and a card reader. If only 
one of them is connected to the system at any one time, you could load 
the driver for the on-line device and unload the other driver, thus 
reducing the size of the Executive. 


A loadable user-written driver is easier to incorporate into a system 
and easier to debug than a resident one. You can incorporate a 
resident driver into a system only during system generation; the 
Executive must be rebuilt and the system bootstrapped each time it is 
incorporated after debugging. In contrast, you can incorporate a 
loadable driver into a system with a single MCR command. 
Incorporating and debugging user-written drivers are discussed in 
Chapter 3. 


INTRODUCTION TO I/O DRIVERS 


1.2 FUNCTION OF AN I/O DRIVER 
An I/O driver is an asynchronous process (not a task) that calls and 
is called by the Executive to service an external I/O device or 
devices. The role of an I/O driver in the RSX-11M I/0 structure is 
specific and limited. A driver performs the following functions: 

e Receives and services interrupts from its I/O device(s) 


e Initiates I/O operations when requested to do so by the 
Executive 


® Cancels in-progress I/0 operations 


e Performs other (device-specific) functions upon power failure 
and device time-out 


As an integral part of the Executive, a driver possesses itsS_ own 
context, allows or disallows interrupts, and synchronizes its access 


to shared data bases with that of other Executive processes. It may 
also synchronize with itself: A driver can handle several device 
controllers (each with several device-units) all operating in 


parallel. A user-written driver must adhere to RSX-11M programming 
conventions in order to ensure the integrity of the Executive. 
Section 2.5 and Chapter 4 discuss these conventions. 


CHAPTER 2 


THE RSX-11M I/O SYSTEM--PHILOSOPHY AND STRUCTURE 


2.1 I/0 PHILOSOPHY 


Memory constraints and compatibility requirements dominated the design 
Philosophy and strategy used in creating RSX-11M. To meet its 
performance and space goals, the RSX-11M I/0 system attempts’ to 
centralize common functions, thus eliminating the inclusion of 
repetitive code in each and every driver in the system. To achieve 
this centralization, a substantial effort has been expended in 
designing the RSX-11M data structures, which are used to drive the 
centralized routines. The effect is to reduce substantially the size 
of individual I/O drivers. The table structures require space and 
must be considered with the total size of the I/0 system. 
Nevertheless, the size reduction effected by centralizing functions, 
combined with table-driven design, enables RSX-11M to meet its 
intended memory and performance goals. 


2.2 STRUCTURE 
The following sections: 


1. Place an I/O driver in the context of the overall RSX-11M I/0 
system 


2. Establish the responsibilities of an I/O driver 


3. Functionally describe the driver's interface to the Executive 
subroutines and the I/O data structures 


2.2.1 1/0 Hierarchy 


The RSX-11M I/O system is structured as a loose hierarchy. The term 
"loose" indicates that you can enter’ the hierarchy at any of its 
levels; this characteristic is contrasted to "tight" hierarchies that 
permit entry only from the top level. Tight hierarchies exist 
Principally for security and protection, but consume equipment 
resources. Figure 2-1 shows the loose RSX-11M I/0 system hierarchy. 


THE RSX-11M I/O SYSTEM-—-PHILOSOPHY AND STRUCTURE 


2.2.1.1 FCS/RMS - At the top of the hierarchy are File Control 
Services (FCS) and Record Management Services (RMS), which provide 
device-independent access to devices included in a given’ system 
configuration. The user task has two levels with which to interface 
with FCS or RMS: Get/Put and Read/Write. Get/Put facilitates the 
movement of data records, whereas Read/Write provides a more basic 
level of access affording more direct control over data movement 
between a task and peripheral devices. 


Non-privileged 


Privileged 


User 1/O 
request 


Device- 
independent 


Device- 
dependent 


aio 
directive 


aio 
directive 


User state 


System state 


aio 
directive 
service 


Executive 
{/O subroutines 


Device interrupt 


1/0 


driver 


ZK-210-81 


Figure 2-1 I/0 Control Flow 


The discussion of FCS and RMS is brief because their existence is 
completely transparent to the driver and rarely concerns the writer of 
a conventional driver. FCS or RMS accepts a user request, interprets 
it, and translates it into a series of low-level system directives 
known as QIOs. 


2.2.1.2 QIO - The QIO directive is the lowest level of task I/O. Any 
task can issue a QIO directive which allows direct control over 
devices that are connected to a system and that have an I/O driver. 
The QIO directive forces all I/O requests from user tasks to go 
through the Executive. The Executive works to prevent tasks from 
destructively interfering with each other and with the Executive 
itself. 
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2.2.1.3 Executive I/O Processing - The Executive processes I/O 
requests using the following: 


1. An Ancillary Control Processor (ACP) 

2. A collection of Executive components consisting of: 
a. QIO directive processing 
b. I/O-related subroutines 
ec. The I/O drivers 


An ACP is responsible for maintaining the structure and integrity of 
data stored on file-structured volumes. It maps virtual I/0 functions 
to logical I/O functions, and makes volume-protection checks. The 
driver converts a logical block number into a physical address on a 
file-structured device. No direct connection normally exists between 
the ACP and a driver. 


An ACP is a privileged task, and requires a partition in which to 
execute. Drivers, on the other hand, are specialized system 
processes, not tasks. 


The Executive provides QIO directive processing. It also provides a 
collection of subroutines that are used by drivers to obtain I/0 
requests, to facilitate interrupt handling, and to return directive 
status codes. Actual control of the device is performed by the 
driver. These subroutines are examined in detail in Chapter 5. 
Executive subroutine services and QIO directive processing are shown 
as distinct components but are, in fact, both part of the Executive. 
These subroutines centralize common driver functions, thus eliminating 
duplicate code sequences among drivers. 


2.2.2 Role of I/O Driver in RSX-11M 


Every I/0 driver in the RSX-11M system has the following five entry 
points: 


e Device interrupt! 
e I/0 initiator 
e Device time-out 
e Cancel I/0 
e Power failure 
The first entry point is entered by a hardware interrupt; the other 


four are entered by calls from the Executive. Functional details 
regarding these entry points follow. 


1. A device may trigger more than one distinct interrupt entry. For 
example, a full-duplex device would have two. 


2-3 
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2.2.2.1 Device Interrupt - Control passes to this entry point when a 
dewice previously initiated by the driver completes an I/O operation 
and causes an interrupt in the central processor. The connection 
between the device and the driver in this instance is direct; the 
Executive is not involved. 


2.2.2.2 I/O Initiator - The Executive calls this entry point to 
inform the driver that work for it is waiting to be done. In effect, 
this is a wake-up signal for the driver. 


2.2.2.3 Device Time-out - When a driver initiates an I/0 operation, 
it can establish a time-out count. If the function then fails to 
complete within the specified time interval, the Executive notes’ the 
time lapse and calls the driver at this entry point. 


2.2.2.4 Cancel I/O - A number of circumstances arise within the 
system that require a driver to terminate an in-progress I/0 
operation. When such a termination becomes necessary, a task so 
informs the Executive, which then relays the request to the driver by 
calling it at the cancel I/O entry point. 


2.2.2.5 Power Failure - The Executive calls the driver's power- 
failure entry point in three different circumstances: 


@ When power is restored after a failure 
e When the system is bootstrapped 


e When the driver is loaded (if it is a loadable, as opposed _ to 
a resident, driver) 


Power Restore - Two conditions can initiate a call to the driver when 
Power is restored following a power failure. First, the Executive 
automatically calls the power-failure entry point when power is 
restored any time the controller is busy (that is, when I/O is in 
Progress). Second, a driver has the option to be called regardless of 
the existence of an outstanding I/O operation at the time the power is 
restored (See the description of the UC.PWF bit symbol in Section 
4.1.4.1). Frequently, a driver's response to a power failure or to an 
I/O failure is identical to that when its device times out; in such a 
case, the power-failure entry point may simply be a RETURN 
instruction, because the driver will recover eventually via the 
time-out entry point. 


Bootstrap - When the system is bootstrapped, a power-failure interrupt 
is simulated. This simulation gives drivers the opportunity to carry 
out any appropriate preoperational initialization. 


Load - The MCR LOA command calls a loadable driver at its 
Power-failure entry point if the device is on line and UC.PWF is set 
{see Section 4.1.4.1). 
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2.2.2.6 Summary--Role of an I/O Driver - Functionally, a driver in 
RSX-11M is responsible for: 


e Servicing device interrupts 
e Initiating I/O operations 
e Cancelling in-progress I/O operations 


e Performing device-related functions when a time-out or power 
failure occurs 


A driver exists as an integral part of the Executive; it can: call; 
and be called by, the Executive. The driver initiates device I/0 
operations directly and receives device interrupts directly. All 
other entry points are entered by means of Executive calls. A driver 
never receives a QIO request directly, and has no direct interaction 
with the ACP. 


2.3 DATA STRUCTURES 
An I/O driver interacts with the following data structures: 
e Device Control Blocks (DCBs) 
e Unit Control Blocks (UCBs) 
e Status Control Blocks (SCBs) 
e The I/0 packet 
e The I/O queue 
e The fork list 
e Device interrupt vector 


The first four of these data structures are especially important to 
the driver, because it is by means of these data structures that all 
I/O operations are effected. They also serve aS communication and 
coordination vehicles between the Executive and individual drivers. 


The I/O queue and the fork list are actually Executive data 
structures, but are discussed here to illustrate all facets of the 
interaction of an I/O driver with the Executive. The I/O queve is a 
list of I/0 packets built by the QIO directive, principally from 
information in the caller's Directive Parameter Block (DPB). The fork 
list synchronizes access to shared Executive data structures. 


Entry to a driver following a device interrupt is accomplished through 
the appropriate hardware device interrupt vector. As will be seen, 
writers of resident drivers are responsible for properly initializing 
this vector. It is discussed in conjunction with the data structures 
associated with a driver. 
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2.3.1 The Device Control Block (DCB) 


At least one DCB exists for each type of device appearing in a system 
(device type should not be equated with device-unit). The function of 
the DCB is to describe the static characteristics (rather than 
execution-time information) of both the device controller and the 
units attached to the controller. All the DCBs in a system form a 
forward-linked list, with the last DCB having a link of zero. Most of 
the data in the DCB is established in the assembly source for the 
driver data structure. The DCB is used by the QIO directive 
procesSing code in the Executive and not by the driver. 


2.3.2 The Unit Control Block (UCB) 


One UCB exists for each device-unit attached to a system. Much of the 
information in the UCB is static, though a few dynamic parameters 
exist.l For example, the redirect pointer, which reflects the results 
of the MCR RED command is updated dynamically. As with the DCB, most 
of the UCB is established in the assembly source; however, its 
contents are used and modified by both the Executive and the driver. 
Usually, either the Executive or the driver -- but not both -- modify 
a datum. 


2.3.3 The Status Control Block (SCB) 


One SCB exists for each device controller in the system. This is true 
even if the controller handles more than one device-unit (like the 
RL11 Controller). Line multiplexers such as the DH11 and DJ1l are 
considered to have one controller for each line because all lines can 
transfer in parallel. Most of the information in the SCB is dynamic. 
Both the Executive and the driver use the SCB. 


2.3.3.1 Interrelation of the I/0 Control Blocks - This’ section 
discusses the interrelationship among the DCB, UCB, and SCB without 
entering into the detailed contents of the control blocks, which are 
discussed in Chapter 4. 


Figure 2-2 shows the data structure that would result for three LA36 
DECwriters interfaced by means of a DH11 multiplexer. The structure 
requires one DCB, three UCBs, and three SCBs, because the activity on 
all three units can proceed in parallel. ; 


Figure 2-3 depicts the internal data structure for an RK1l1l disk 
controller with three units attached. Note that only one SCB exists, 
because only one of the three units can be active at any given time. 


1. From the UCB, however, it is possible to access most of the other 
Structures in the I/O data base (see Figure 2-5). In this sense the 
UCB gives access to a large amount of dynamic data. 
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Figure 2-4 shows the data structure for two RKl1l disk controllers, 
each of which has two drives attached. Here there are two SCBs, 
because both of the disk controllers can operate in parailel. 


Taken together, Figures 2-2, 2-3, and 2-4 illustrate the strategy 
underlying the existence of three basic I/O control blocks. There 
need be only one DCB for each device type. There may be one or more 
SCBs, depending on the degree of parallelism that is desired or 
possible: one for each device-unit, or one for each controller 
servicing several device-units. The number of UCBs and SCBs, and 
their interrelationships, are uniquely determined by the hardware 
these data structures describe. 


This data structure provides considerable flexibility in configuring 
I/O devices, and, because of the information density in the structures 
themselves, substantially reduces the code requirements of the 
associated drivers. 


ZK-211-81 


Figure 2-2 DH11 Terminal I/O Data Structure 
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ZK-212-81 


Figure 2-3 RK1l Disk I/O Data Structure 


ZK-213-81 


Figure 2-4 I/0 Data Structure for Two RK11 Disk Controllers 


2.3.4 The I/O Packet 


An I/O packet contains information extracted from the QIO DPB, as well 
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2.3.5 The I/O Queue 5 


Each time a task makes an I/O request, the Executive performs a series 
of validity checks on the DPB parameters. If these checks prove 
successful, the Executive generates a data structure called an I/0 
packet. The Executive then inserts the packet into a device-specific, 
Priority-ordered list of packets called the I/0 queue. Each I/0 
queue's listhead is located in the SCB to which the I/O requests 


apply. 


When a device driver needs work, it requests the Executive to dequeue 
the next I/0 packet and deliver it to the requesting driver. 
Normally, the driver does not directly manipulate the I/O queue. 


2.3.6 The Fork List 


The fork list is a mechanism by which RSX-11M splits off processes 
that require access to shared data bases, or that require more CPU 
time to process an interrupt than is compatible with fast, real-time 
response of the overall system. 


A process that calls SFORK requests the Executive to transform it into 
a "fork process" and place it on the fork list. What this means is 
that a call to $FORK saves a "Snapshot" of the process (registers R4, 
R5, and the PC) ina fork block. This fork block is queued on the 
fork list in first-in-first-out (FIFO) order. 


When a fork process has worked its way to the front of the fork list, 
R4 and R5 are restored and execution restarts at the statement after 
CALL $FORK. The process is unaware that a pause of indeterminate 
length has occurred. 


A fork process exists in a status intermediate between an interrupting 
routine and an ordinary task requesting system resources. Routines in 
the system stack--requests for interrupt processing--are run _ first. 
They can be interrupted only by higher-priority requests. Routines in 
the fork list are run when the system stack is empty--that is, they 
are completely interruptable. Finally, other tasks are run only when 
both the system stack and the fork list are empty. 


Driver interrupts are processed at priority 7 and are thus 
noninterruptable. By system convention, no process should run in a 
noninterruptable mode for more than 100 microseconds. This convention 
ensures prompt attention to interrupting real-time events. 


In practice, drivers servicing interrupts drop from priority 7 to a 
lower priority (namely, that of the interrupting source) after issuing 
a few instructions. Another system convention states that processing 


1. An exception is the case in which a driver needs to examine an I/0 
packet before it is queued, or in place of having it queued. For the 
driver to accomplish this examination, you must set the bit UC.QUE in 
the control byte (U.CTL) of the UCB (described in Section 4.1.4). 


The most common reason for a driver to examine a packet before queuing 
is that the driver employs a special user buffer, other than the 
normal buffer used in a transfer request. Within the context of the 
requesting task, the driver must address-check and relocate such a 
special buffer. See Section 6.3 for an example of a driver that does 


this. 
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at this partially interruptable level should not exceed 500 
microseconds. Often, more time than this is required to process an 
interrupt. The fork list mechanism provides a secondary interrupt 
stack whose members are processed first-in-first-out whenever the 
system stack is empty. 


A process can also call $FORK to access a shared data base--a system 
table, for example. You must strictly control such access in order to 
avoid conflicts. Under RSX-11M, many drivers can run in parallel; a 
multicontroller driver can run in parallel with itself. In these 
circumstances access to common data bases must be controlled. 


Of the two available methods of controlling such access--interrupt 
lockout and priority queuing--RSX-11M uses priority queuing. The fork 
list is the queue of requests for such access. Fork processes are 
granted FIFO access to common data bases. Once granted such access, a 
process is guaranteed control of the data base until it exits. 


2.3.7 The Device Interrupt Vector 


The device interrupt vector consists of two consecutive words giving 
the address of the interrupt-service routine and the priority at which 
it is to run (always set to PR7). The low four bits of the _ second 
word of the interrupt vector must contain the number of the controller 
that interrupts through the vector. This requirement enables a driver 
to service several controllers with few code changes (see Sections 4.2 
and 4.3 for an example and discussion of multicontroller driver 
coding). Generally, these bits are set to 0. 


2.4 EXECUTIVE SERVICES 


The Executive provides services related to I/O drivers that can be 
categorized as pre- and post-driver initiation. The preinitiation 
services are those performed by the Executive during its processing of 
a QIO directive; these services are not available as Executive calls. 


The goal of pre-driver initiation processing is to extract from the 
QIO directive ail I/0 support functions not directly related to the 
actual issuance of a function request to a device. If the outcome of 
pre-driver initiation processing does not result in the queuing of an 
I/O packet to a driver, the driver is unaware that a QIO directive was 
issued. Many QIO directives do not result in the initiation of an I/0 
operation. 


The post initiation services are those available to the driver after 
it has been given control, either by the Executive or as the result of 
an interrupt. They are available as needed by means of Executive 
calls. 


An important concept used in this section and in Section 2.5 is the 


"state" of a process. In RSX-11M, a process can run in one of two 
states: user or system. DriverS operate almost entirely in the 
system state; the programming standards described in Section 2.5 


apply to system-state processes. 
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Pre-Driver Initiation Processing 


In processing a QIO directive, the Executive module DRQIO performs the 
following pre-driver initiation services: 


l. 


2. 


Checks to verify whether the supplied logical unit number 
(LUN) is legal. If not, the directive is rejected. 


If the LUN is valid, checks to verify whether a valid UCB 
pointer exists in the Logical Unit Table (LUT) for the 
specified LUN. This test determines if the LUN is assigned. 
If the test fails, the directive is rejected. 


If steps 1 and 2 are successful, traces down the redirect 
chain to locate the correct UCB to which the I/0 operation 
will actually be directed. 


Checks the event flag number (EFN) and the address of the I/0 
Status Block (IOSB). If either is illegal, the directive is 
rejected. Immediately following validation, the Executive 
resets the subject event flag and clears the IOSB. 


Obtains 18 words of dynamic’ storage and builds the 
device-independent portion of an I/O packet. 


If steps 1 through 5 succeed, the Executive sets’ the 
directive status to +l. 


Note that directive rejections in any of the above steps are 
completely transparent to the driver. Such rejections cause 
a return of carry bit set. 


Checks the validity of the function being requested and, if 
appropriate, checks the buffer address, byte count, and 
alignment requirements for the specified device. 


If any of these checks fails, the Executive calls the I/0 
Finish routine (SIOFIN). SIOFIN sets the I/O status and 
clears the QIO request from the system. 


If the requested function does not require a call to the 
driver, the Executive takes the appropriate actions and calls 
SIOFIN. 


If all I/0 packet checks are positive, the Executive places 
the I/0 packet in the driver queue according to the priority 
of the requesting task, or gives the packet to the driver (if 
bit UC.QUE is set--see Section 4.1.4.1). 


2.4.2 Post-Driver Initiation Services 


Once a driver is given control following an I/O interrupt or by the 


Executive 


driver. 


itself, a number of Executive services are available to the 
These services are discussed in detail in Chapter 5. 
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However, four Executive services merit special emphasis because 
virtually every driver in the system uses them: 


e Interrupt Save (SINTSV) 
e Get Packet ($GTPKT) 
e Create Fork Process (S$FORK) 


@ 1/0 Done ($IODON or SIOALT) 


2.4.2.1 Interrupt Save (SINTSV)1 - Interrupts from a device are 
fielded by the driver. Immediately following the interrupt, the 
driver operates at hardware priority level 7 and is, therefore, 
noninterruptable. If the driver needs a lengthy processing cycle 
(greater than 100 microseconds) to process the interrupt, or if it 
requires the use of any general-purpose registers, it calls SINTSV. 
This call queues external interrupts, alters the hardware priority, 
and provides the calling routine with two free registers to use in 
processing the interrupt. SINTSV is discussed in more detail in 
Section 2.5. 


2.4.2.2 Get Packet (SGTPKT) - The Executive, after it has queued an 
I/O packet, calls the appropriate driver at its I/O-initiator; entry 
point. The driver then immediately calls the Executive routine $GTPKT 
to obtain work.2 If work is available, S$GTPKT delivers to the driver 
the highest-priority, executable I/O packet in the driver's I/O queue, 
and sets the SCB status to "busy." If the driver's I/O queue is empty, 
SGTPKT returns a no-work indication. If the SCB related to the device 
is already busy, S$GTPKT so informs the driver, and _ the driver 
immediately returns control to the Executive.. 


Note that, from the driver's point of view, no distinction exists 
between no-work and SCB busy, because an I/O operation cannot be 
initiated in either case. 


2.4.2.3 Create Fork Process (S$FORK) - You can synchronize access to 
shared data bases by creating a fork process. When a driver needs to 
access a Shared data base, it must do so as ae fork process; the 
driver becomes a fork process by calling $FORK. The SCB contains 
preallocated storage for a 4- or 5-word "fork block." See Section 
4.1.3.1 for a description of the fork block. Section 5.3 contains 
details on S$FORK. 


1. A loadable driver on a mapped system cannot call SINTSV directly. 
See Section 4.3. 


2. An exception is a driver that handles special user buffers. Such a 


driver must call certain other Executive routines before calling 
SGTPKT. See Section 6.3 for an example. 
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An interrupt routine cannot call S$FORK directly; the routine must 
First switch to system state by using the INTSVS macro or calling 
SINTSV (as described in Section 2045-201) % Furthermore, the 
interrupting routine's priority is lowered to that of the requesting 
source. 


After calling $FORK, a routine is fully interruptable (priority 0), 
and its access to shared system data bases is strictly linear. 


2.4.2.4 I/0 Done (SIODON or $IOALT) - At the completion of an I/0 
request, the subroutines SIODON or SIOALT perform a number of 
centralized checks and additional functions: 


e Store status if an IOSB address was specified 

e Set an event flag, if one was requested 

e Determine if a checkpoint request can now be honored 
e Determine if an AST should be queued 


SIODON and SIOALT also declare a significant event, reset the SCB_ and 
device unit status to "idle," and release the dynamic storage used by 
the completed I/O operation. 


2.5 PROGRAMMING STANDARDS 


RSX-11M I/O drivers function as integral components of the RSX-11M 
Executive. They must follow the same conventions and protocol as the 
Executive itself if they are to avoid complete disruption of system 
service. This manual has been written to enable you to incorporate 
I/O drivers into your system. Failing to observe the _ internal 
conventions and protocol can result in poor service and a reduction in 
system efficiency. 


2.5.1 Process-Like Characteristics of a Driver 


A driver is an asynchronous Executive process. AS a process, it 
possesses its own context, allows or disallows interrupts, and 
synchronizes functions within itself (all drivers can be parallel, 
multiunit, multicontroller) and with other Executive processes 
executing in parallel. 


Most RSX-11M drivers are small. Their small size is made possible by 
a comprehensive complement of centralized services available by calls 
to the Executive, and by the availability of an information-dense, 
highly formalized I/O data structure. 


2.5.2 Programming Conventions 


Appendix E of the PDP-11 MACRO-11 Language Reference Manual describes 
program coding standards. DIGITAL recommends that users refer to 
these standards to assist in preparing standards for their own 
installations. 
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2.5.3 Programming Protocol 


Because an I/O driver accepts interrupts directly from the devices it 
controls, the central Executive relies on the driver to follow strict 
Programming protocol so that system performance is not degraded. 
Furthermore, the protocol ensures that the driver properly distributes 
shared resources according to user-specified priorities. The protocol 
is summarized in Section 2.5.3.4. 


When a device interrupts, an I/O driver is entered. The driver 
usually calls SINTSV or issues the INTSV$ macrol for common save and 
State-switching services. At the completion of the services provided 
by INTSVS or SINTSV, the interrupt routine is again given control to 
complete the interrupt service. The exit routine SINTXT restores’ the 
State prior to switching to the system state, controls the unnesting 
of interrupts, and makes checks on the state of the system (for 
example, it checks to determine whether it is necessary to switch 
Stacks). The fork processor causes access to shared system data bases 
to be linear. The details of all these routines are given in Chapter 
a 


The interrupt vectors for each controller type in low memory contain a 
Program counter (PC) unique to each interrupting source and a 
Processor Status Word (PSW) set with a priority of 7. It is a system 
software convention to use the low-order four bits of the PSW to 
encode the controller number for multicontroller drivers. When a 
device interrupt occurs, the hardware pushes the current PSW and PC 
onto the current stack and loads the new PC and PSW (Set at priority 7 
with the controller number in the condition-code bits) from the 
appropriate interrupt vector. The driver then starts executing with 
interrupts locked out. A driver itself may be executing at one of 
three levels of interrupt sensitivity: 


1. At priority 7 with interrupts locked out. 


2. At the priority of the interrupting source; thus, interrupt 
levels greater than the priority of the interrupting source 
are permitted. 


3. At fork level, which is at priority 0. 


2.5.3.1 Processing at Priority 7 with Interrupts Locked Out - By 
internal convention, processing at this level is limited to 100 
microseconds. If processing can be completed in this time, either 
without using general-purpose registers or by saving and restoring the 
registers used, then the driver simply dismisses the interrupt by 
executing an RTI instruction. The interrupt iS processed and 
dismissed with minimal overhead. 


2.5.3.2 Processing at the Priority of the Interrupting Source - If 
the driver requires additional processing time or requires the use of 
general-purpose registers, it calls the SINTSV_ routine. Loadable 
drivers on mapped systems must use the INTSVS macro. All other 
drivers can use the INTSVS macro or call the SINTSV routine directly. 
The priority at which the caller is to run is included in the call to 
the SINTSV routine. The driver sets this priority level to that of 
the interrupting source. 


1. The system macro INTSVS$ simplifies the coding of standard 
interrupt-entry processing (see Section 4.3). 
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The SINTSV routine sets up the interrupt routine so that it can be 
interrupted by devices with priorities higher than that of the 
interrupting source, and switches to system state if the processor is 
not already in system state. 


The SINTSV routine also saves registers R4 and R5 to free these 
registers for the driver. (A standard practice is for the driver to 
set R4 to the address of the interrupting device's SCB, and R5 to its 
UCB address.) An internal programming convention assumes that the 
driver will not require more than these two registers during interrupt 
processing. If it does, the driver must save ‘and restore any 
additional registers it uses. Processing time following the return 
from the SINTSV routine should not exceed 500 microseconds.1l 


NOTE 


In actual practice, every driver in the 
system calls the SINTSV routine on every 
interrupt, due to three factors: 


l. It is difficult to service an 
interrupt without using one or two 
registers. 


2. Most interrupt code can safely be 
executed at the priority of the 
interrupting source. Executing at 
that priority is more desirable in 
terms of system response than 
continuing to execute at the highest 
priority. 


3. The SINTSV routine is an _ integral 
part of the interrupt mechanism for 
loadable drivers. 


2.5.3.3 Processing at Fork Level - A driver calls S$FORK to _ become 
fully interruptable (so that it conforms to the 500-microsecond time 
limit), or to access the shared system data base. The INTSVS macro 
must be issued or the SINTSV routine must be called prior to calling 
SFORK. 


By calling S$FORK, the routine becomes fully interruptable and its 
access to system data bases is strictly linear. At fork level, all 
registers are available to the process, and R4 and R5 retain the 
contents they had on entrance to S$FORK. 


1. The 500-microsecond period is a guideline. The longer the _ period 
of time a real-time executive spends at an elevated priority level, 
the less responsive is the system to devices of equal or lower 
priocrity.« This guideline is especially important if the device being 
serviced is at the same or higher priority than a character-interrupt 
device such as the DU11, which is vulnerable to data loss due to 


interrupt lockout. 
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2.5.3.4 Programming Protocol Summary - Drivers are required to adhere 
to the following internal conventions when processing device 
interrupts: 

1. No registers are available for use unless SINTSV has been 
called or the driver explicitly performs save and restore 
operations. If SINTSV is calied, registers R4 and R5 are 
available; any other registers must be saved and restored. 

2. Noninterruptable processing must not exceed twenty 
instructions, and processing at the priority of the 
interrupting source must not exceed 500 microseconds. 

3. You must use a fork process for all modifications to system 


data bases. 


2.6 FLOW OF AN I/O REQUEST 


Following an I/O request through the system at the functional level 
(the level at which this chapter is directed) requires that limiting 
assumptions be made about the state of the system when a task issues a 
QIO directive. The following assumptions apply: 


The system is up and ready to accept an I/O request. All 
required data structures for supporting devices attached to 
the system are intact. 


The only I/O request in the system is the sample request 
under discussion. 


The example progresses without encountering any errors’ that 
would prematurely terminate its data transfer; thus, no 
error paths are discussed. 


The I/O flow proceeds as follows: 


1. 


{Task issues QIO directive] 


All Executive directives are called by means of EMT 377. The 
EMT causes the processor to push the PSW and PC on the stack 
and to pass control to the Executive's directive processor. 


a. First-level validity checks 


The QIO directive processor validates the LUN and UCB 
pointer. 


b. Redirect algorithm 


Because the UCB may have been dynamically redirected 
by an MCR Redirect command, QIO directive processing 
traces the redirect linkage until the target UCB is 
found. 


c. Additional validity checks 
The EFN and the address of the I/0 status’ block 


(IOSB) are validated. The event flag is reset and 
the I/O status block is cleared. 


2. 
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[Executive obtains storage for and creates an I/0 packet] 


The QIO directive processor now acquires an 18-word block of 
dynamic storage for use as an I/O packet. It inserts into 
the packet data items that are used subsequently by both the 
Executive and the driver in fulfilling the I/O request. Most 
items originate in the requesting task's Directive Parameter 
Block (DPB). 


[Executive validates the function requested] 
The function is one of four possible types: 
e Control 
e No-op 
e@ ACP 
e Transfer 


Control functions are queued to the driver. If the function 
is IO.KIL, the driver is called at its cancel I/0 entry 
point. The IO.KIL request is then completed successfully. 


No-op functions do not result in data transfers. The 
Executive "performs" them without calling the driver. No-ops 
return a status of IS.SUC in the I/O status block. 


ACP functions may require processing by the file system. 
More typically, the request is a read or write virtual 
function that is transformed into a read or write logical 
function without requiring file system intervention. When 
transformed into a read or write logical, the function 
becomes a transfer function (by definition). See Appendix D 
for more information on ACP functions. 


Transfer functions are address checked and queued to. the 
Proper driver. Then the driver is called at its initiator 
entry point. 


[Driver processing] 
ae Request work 


To obtain work, the driver calls the S$GTPKT routine. 
SGTPKT either provides work, if it exists, or informs the 
driver that no work is available, or that the SCB is 
busy. If no work exists, the driver returns to its 
caller. If work is available, SGTPKT sets the device 
controller and unit to "busy," dequeues an I/O request 
packet, and returns to the driver. If the I/O request is 
IO.ATT or I0O.DET, the request iS processed by the 
Executive without returning the packet to the driver, 
unless UC.QUE is set. 


If UC.QUE is set, the packet is passed to the driver 
after the I0.ATT or IO.DET processing is completed. If 
the request is to be processed by an ACP, the packet is 
queued to the ACP. In either case, $GTPKT will look for 
another request for the driver. 
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b. Issue I/0 


From the available data structures, the driver initiates 
the required I/O operation and returns to its caller. A 
subsequent interrupt may inform the driver that the 
initiated function is complete, assuming the device is 
interrupt driven. 


5. [Interrupt processing] 


When a previously issued I/0 operation interrupts, the 
interrupt causes a direct entry into the driver, which 
Processes the interrupt according to the programming protocol 
described in Section 2.5. According to the protocol, the 
driver may process the interrupt at priority 7, at the 
priority of the interrupting device, or at fork level. If 
the processing of the I/O request associated with the 
interrupt is still incomplete, the driver initiates further 
I/O on the device (step 4b). When the processing of an I/O 
request is complete, the driver calls SIODON. 


6. [1/0 Done processing] 


SIODON removes the "busy" status from the device unit and 
controller, queues an AST, if required, and determines if a 
checkpoint request pending for the issuing task can now be 
effected. The IOSB and event flag, if specified, are 
updated, and SIODON returns to the driver. The driver 
branches to its initiator entry point and looks for more work 
(step 4a). This procedure is followed until the driver finds 
the queue empty, whereupon the driver returns to its caller. 


Eventually, the processor is granted to another ready-to-run 
task that issues a QIO directive, starting the I/O flow anew. 


2.7 DATA STRUCTURES AND THEIR INTERRELATIONSHIPS 
This section introduces all the individual control blocks, as well as 
their linkages and use within the system. The following data 
structures comprise the complete set for I/O processing: 

1. Task header 

2. Window Block (WB) 

3. File Control Block (FCB) 


4, SDEVHD word, the Device Control Block (DCB), and the Driver 
Dispatch Table (DDT) 


5. Unit Control Block (UCB) 

6. Status Control Block (SCB) 

7. Volume Control Block (VCB) 
Figure 2-5, which provides the structure for the following discussion, 
shows all the individual data structures and the important link fields 


within them. The numbers on the figure are keyed to the text to 


simplify the discussion and to guide the reader through the data 
structures. 
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1. The task header is constructed during the task-build 
process.!| (It is one of two independent entries in the I/0 
data structure, the other being S$DEVHD.) The task header 
entry of interest, the Logical Unit Table (LUT), is allocated 
by the Task Builder and filled in at task installation. The 
number of LUT entries is established by the UNITS= keyword 
option; this number is an upper limit on the number of 
device units a task may have active simultaneously. Each LUT 
entry contains a pointer to an associated UCB, and a_ pointer 
to a Window Block if a file is accessed by that logical unit 
number (LUN). 
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Figure 2-5 I/0 Data Structure 


2. A Window Block (WB) exists for each active access to files on 
a mounted volume. It contains the context for the virtual 
patch used for validating I/O requests and converting virtual 
functions to logical functions. For disks, the WB consists 
of pointers to contiguous areas on the device. 


3. An FCP is a data structure specific to the Files-ll disk ACP 
(FIIACP). It is used to control access to the file. 


1. In mapped systems, a copy of the task header (located in the task's 
partition) is made in the Executive's dynamic storage region. The 
Executive then uses this copy. To access the current information in 
this copy, a task must be privileged and have mapping to the 
Executive. 
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4. SDEVHD is a word located in system common (SYSCM) and is’ the 
other independent entry in the I/O data structure. $DEVHD 
points to a singly linked, unidirectional list of Device 
Control Blocks (DCBs). Each device type in a system has at 
least one associated DCB. The DCB list is terminated by a 
zero in the link word. 


Linked to each DCB is a Driver Dispatch Table (DDT), which is 
Part of the driver. The DDT contains the addresses of the 
driver's four entry points that the Executive can call. 


5. <A key data structure is the Unit Control Block (UCB). All 
the UCBS associated with a DCB appear in consecutive memory 
locations. During internal processing of an I/O request, 
most drivers set R5 to the address of the related UCB. It is 
by means of pointers in the UCB that other control blocks in 
the data structure are accessed. In particular, the UCB 
contains pointers to the DCB, SCB, VCB, and to the UCB to 
which it may have been redirected. If a Redirect command has 
not been issued for the device-unit, the UCB redirect pointer 
points to the UCB itself. When servicing a request for one 
of its UCBs, the driver is unaware of whether I/O was’ issued 
directly to its own UCB or to a UCB that had been redirected 
to its UCB. 


6. One Status Control Block (SCB) exists for each controller in 
a system. A unique SCB must exist for each 
controller/device-unit capable of performing parallel I/0. 
The SCB contains the fork-block storage required when a 
driver calls $FORK to transfer itself to the fork-processing 
level. The I/O request queue listhead is also contained in 
the SCB. Generally, register R4 contains the address of the 
SCB during processing of an I/O request. 


7. One Volume Control Block (VCB) exists for each mounted volume 
in a system. The VCB maintains volume-dependent control 
information. 


For Filies-1l disks, the VCB contains pointers to the File 
Control Definition Block (FCB) and Window Block (WB), which 
control access to the volume's index file. (The index file 
is a file of file headers.) The WB for the index file serves 
the same function as the WB for aeuser file. (See the 
IAS/RSX-11 170: Operations Reference Manual for more 
information on the index file.) All unique FCBs for a volume 
form a linked list emanating from the index file FCB. This 
linkage aids in keeping file access time short. Further, 
Since the window that contains the mapping pointers is 
variable in length, the user can increase file access speed 
by adding more access pointers (greater speed requires more 
main memory) to whatever extent the application requires. 


2.7.1 Data Structures Summary 


As the writer of a conventional driver, you do not manipulate the 
entire I/O data structure. In fact, you are uSually involved only 
with the I/O packet, the UCB, and the SCB. The entire structure has 
been presented to add depth to your understanding of the I/O system, 
to emphasize the relationships among individual control blocks, and to 
clarify further the role a given driver fulfills in the processing of 
an I/O request. 


CHAPTER 3 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


If you want to support an I/O device for which DIGITAL has not 
supplied a driver, you can write your own driver. Although this 
manual has not yet presented explicit details for writing such a 
driver, you now have enough conceptual information to consider 
incorporating one of your own drivers into your system. As will be 
seen, many considerations for writing a driver are best presented in a 
discussion of incorporating one. 


NOTE 


An alternative approach to writing your 
own device driver may be the CINTS 
(Connect to Interrupt Vector) directive. 
Refer to the description of the CINTS 
directive in the RSX-11M/M-PLUS 
Executive Reference Manual. For 
examples of the use of CINTS, examine 
the task-level support routines for 
K-series laboratory peripheral modules, 
as described in Chapter 22 of the 
RSX-11M/M-PLUS I/0 Drivers Reference 
Manual. —— 


3.1 OVERVIEW OF INCORPORATING USER-WRITTEN DRIVERS 


How you incorporate a user-written driver into the system depends 
mainly on whether you make your driver loadable or resident. If your 
driver is loadable, its data base can be either loadable or resident. 
If your driver is resident, both its data base and its code are 
resident. Thus, because you build the Executive image during system 
generation, you must include all resident driver elements in the 
Executive image during system generation. If your driver is loadable 
and has a loadable data base, you can incorporate it at any time after 
you build the Executive under which the driver runs. 


3.1.1 System Generation Support for User-Written Drivers 


During system generation, you answer questions concerning the types 
and quantity of peripheral devices on your system. Based on your 
answers, SYSGEN creates a single source file SYSTB.MAC that 
constitutes the data base definitions for DIGITAL-supplied devices on 
the system. Also created are the object modules of driver code to 
support the devices. Assembling SYSTB.MAC creates one module, 
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SYSTB.OBJ, which becomes the system device tables for the Executive 
and the data base for the system drivers. This module is linked into 
and becomes a permanent part of the Executive. 


A privileged system task invoked with the MCR/VMR LOA command is 
responsible for loading into memory a driver that is not resident. 
The LOA function creates the necessary interrupt control blocks (ICB) 
for accessing a driver in a mapped system, and establishes the linkage 
between the data base structures in the system device tables and_ the 
driver code being loaded. Another privileged system task invoked with 
the MCR/VMR UNL command can remove a loadable driver from memory. 
(Although the UNL function removes a loadable driver, it does not 
remove a loadable data baSe.) 


SYSGEN asks questions concerning the necessary driver support features 
in the Executive, to allow you to add user-written drivers. 


During the Target Configuration section of SYSGEN Phase I, answer’ the 
following question with the highest vector your system will use with 
the addition of your user-written driver: 


14. Highest interrupt vector [0 R:0-774 D:0]: 

SYSGEN uses the specified address or 400, whichever is greater, to 
allocate sufficient vector space in the Executive to avoid run-time 
destruction of the system stack and to avoid hardware trapping (which 
occurs when the SP goes below 400). 


If any user-written driver is to be built loadable, SYSGEN must be 


notified of this fact. Loadable drivers require extra Executive 
features to support them (for example, the MCR/VMR LOA and _ UNL 
commands). You can choose support for loadable drivers by answering 


the following question in the Executive Options section of SYSGEN 
Phase I: 


15. Loadable device drivers? [Y/N]: 


The answer to the following question determines whether SYSGEN allows 
you to include a user-written driver in the system: 


25. Do you intend to include a user-written driver? [Y/N]: 


If you answer Yes, the next two questions are also asked (see Section 
5.3 of this manual): 


26. Include routine SGTWRD? [Y/N]: 
27. Include routine $PTWRD? [Y/N]: 


If an LPAl1 device (LA:) is included in 
your system, the SGTWRD routine is 
automatically included and Question 26 
is not asked. If an ADOl A/D controller 
device or an AFCl1l A/D controller device 
(AF:) is included in your system, the 
SPTWRD routine is automatically included 
and Question 27 is not asked. The 
SGTWRD and $PTWRD routines are described 
in Chapter 5 of this manual. 


To incorporate a user-written driver into RSX-11M, you first create 
two modules, one in which you define the data base and the other in 
wnich you include the driver code itself. You then must link your 
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driver data base and driver code modules into the system device 
tables in the Executive. The linkage that your data base module must 
satisfy is the link of the Device Control Block (DCB) list. The 
linkage for the driver code connects the DCB for the device that your 
driver supports to the Driver Dispatch Table (DDT). Moreover, if your 
driver is loadable, you must supply in your driver code symbols and 
labels that the LOA command needs. 


If your driver is loadable and has a loadable data base, you build (1) 
a loadable image containing the driver code module followed by the 
driver data base module, and (2) a symbol definition file on which the 
LOA command depends to find critical data base and driver locations. 
You build the driver image with the symbol definition file of the 
Executive under which the driver runs. However, the driver image is 
separate from the Executive image. The LOA command is responsible for 
loading both your driver data base and driver code, for connecting the 
data base to the system device tables, and for connecting your driver 
code to the data base. 


If your driver is loadable but has a resident data base, you must 
perform SYSGEN and build the Executive under which the driver runs to 
link your driver data base module(s) into the system device tables. 
This operation makes your driver data base resident with the system 
device tables. You also build (1) a loadable image containing’ the 
driver code, and (2) a symbol definition file which the LOA command 
uses to locate the driver dispatch table. The LOA command is 
responsible for loading your driver code and for connecting your 
driver code to the data base that is resident with the system device 
tables. 


If your driver is resident, you must perform a system generation and 
build the Executive to link the driver data base into the system 
device tables and to include the driver code in the Executive image. 


Because the LOA command provides consistency and validity checks on a 
data base being loaded, DIGITAL recommends that you make your driver 
and its data base loadable. Furthermore, with a loadable driver and 
loadable data base, you can more eaSily modify your driver and its 
data base. You need not rebuild your Executive and privileged tasks. 
To change the driver code, you need only build a new driver image, 
unload the current version, and reload the new version. To change the 
driver data base, you must build a new driver image (which 
incorporates the data base module), rebootstrap your system, and _ load 
the new driver to load the modified data base. (You must bootstrap 
your system to change the data base because the UNL command does not 
unload a data base, and because the LOA command does not load a data 
base for a driver if one is currently loaded for that driver.) 


NOTE 


If you use VMR to load the data base 
into the system image, rebooting the 
system will always load the data base. 


Using a loadable driver with a loadable data base may make more work 
in the short term but saves work in the long term. During debugging, 
data base inconsistencies are likely to be caught by the LOAD command. 
Thus, you prevent many such errors from later creating system 
problems. The procedure to make your driver operational is more 
complex because both the driver (and its data base) must be loaded 
each time the system starts up. 
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A resident driver or a loadable driver with a resident data base is 
easier to incorporate into the system but more difficult to debug and 
to modify. The LOA command does not perform consistency and validity 
checks on a reSident data base. Thus, a debugging aid is not 
available. Moreover, to modify such drivers, you must’ rebuild the 
Executive, which generally implies rebuilding the privileged tasks. 


The capability to incorporate a user-written driver into your system 
is a supported feature of RSX-11M. Because a user-written driver is 
considered a system modification, DIGITAL may not support the system 
that results after you incorporate your driver. Being a part of the 
Executive, your driver can subtly corrupt it. Therefore, DIGITAL 
cannot guarantee support which entails debugging user-written drivers. 
Fixing a problem in a system is largely a matter of being able to 
reproduce the problem reliably. If a problem on your system can be 
shown to have no relation to your driver, and DIGITAL will reproduce 
the problem, SPR support can be provided. A good reason for using a 
loadable driver with a loadable data base is that you can more easily 
test an unmodified system by not loading your driver and its data 
base. You can then reproduce a suspected problem in an _ unmodified 
system and can submit an SPR that DIGITAL will answer. Therefore, 
attempting to re-create a suspected problem on your system without 


your driver and its data base saves both you and DIGITAL time in 
answering the SPR. 


3.1.2 Overview of User-Written Driver Code 


To create the source code to drive a device, you must do_ the 
following: 


1. Thoroughly read and understand this manual. 


2. Familiarize yourself in detail with the physical device and 
its operational characteristics. 


3. Determine the level of support required for the device. 
4. Create the data base Source code for the device. 


5. Determine actions to be taken at the five driver entry 
points: 


e Initiator 
e Cancel I/0 
e Time-out 

@ Powerfail 


e Interrupt 
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Create the driver source code. This code will contain the 
following global symbols (where xx is the 2-character 
alphabetic device mnemonic): 


$xxTBL:: Address of the driver dispatch table (see 
Section 4.1.2.1) 

SxxINT:: Address of the driver interrupt entry point 

SxxINP:: Addresses of input and output interrupt 

SxxOUT:: entry points (for full-duplex devices) 


If a loadable driver's loadable data base is to include the 
interrupt vector(s) for the case when the driver is resident, 
the conditional assembly symbol LDSxx must be included in the 
Source code for the loadable data base. In addition, the 
code in the data base which includes the interrupt vector(s) 
must be enclosed in a conditional assembly block and defined 
as an ASECT. 


Loadable drivers have an additional requirement. Either 
within the driver source code itself or in file RSXMC.MAC, 
the conditional assembly symbol LDS$xx must be defined. The 
INTSVS$ macro (see Section 4.3) uses this symbol (and others 
in RSXMC.MAC) to determine whether the call to SINTSV should 
be omitted from the driver. 


The symbols used to name interrupt entries are different for 
devices that employ error logging. See the RSX-11M/M-PLUS 
Error Logging Reference Manual for information on modifying 
device drivers for error logging. Note that the error logger 
must be modified to log errors for a device that uses a 
user-written driver. 


The DIGITAL-supplied terminal driver (TTDRV) is treated as a 
special case by the LOA command in terms of the naming of its 
interrupt entries. 


3.1.3 Overview of User-Written Driver Data Bases 


Of the data structures associated with an I/O driver, four require 
assembly source code: 


The 
The 
The 


The 


DCB 
UCB (s) 
SCB (s) 


device interrupt vector (assembly source 


resident drivers only) 


required for 
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A single DCB can service multiple UCBs and _ SCBs. The existence of 
multiple UCBs and SCBs is determined by the actual device subsystem 
being supported by a given driver in your hardware configuration. 
Figures 2-2, 2-3, and 2-4 illustrate possible DCB, UCB, and SCB 
Structural relationships. 


Within the DCB, UCBs, and SCBs, only those fields that are static or 
that need initialization must be supplied in your assembly source. 
Tables 3-1, 3-2, and 3-3 list these required fields. See Chapter 4 
for detailed figures and descriptions of these and other data 
structures. 


Table 3-1 
Required DCB Fields 


D.LNK Link to next DCB. This field is zero if this is’ the 
last (or only) DCB. If you are incorporating more 
than one uSer-written driver at one time, then this 
field should point to another DCB in a DCB chain. 


Address of the first word (U.DCB) of the first UCB 
associated with this DCB. 


D.UCB 


D. NAM Two-character ASCII generic device name. 


D.UNIT 


Highest and lowest logical unit numbers controlled by 
this DCB. 


D.UCBL 


Length of the UCB (including prefix words, if any). 
If a given DCB has multiple UCBs, all UCBs must be of 
the same length. 


Address of the driver dispatch table. The dispatch 
table is located within the driver code. This field 
contains a global reference to the label associated 
with this table. The field is zero if the driver is 
loadable. 


I/O function masks. You must supply bit-by-bit 
mapping for these four I/O function masks. Note that 
the format of the mask words is split into two groups 
of four words. Functions 0-15. are covered by the 
first group, and functions 16.-31. by the second. 

D. PCB Address of driver Partition Control Block (PCB). 
This field is required only if loadable driver 
support is included in the system. It must be 
initialized to zero. 
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Table 3-2 
Required UCB Fields 


Description 


j oessee | 


Backpointer to the associated DCB 


Redirect pointer-~initially contains the address of 
this UCB 


Control bits that must be established by the driver 
writer with the UCB source | 


U.STS Unit status byte 
U.UNIT Physical unit number serviced by this UCB 


Unit status byte extension 


Characteristics word 1; Standard description (see 
Section 4.1.4.1) applies 


Driver-dependent 
Driver-dependent 

Default buffer size 

Address of the SCB for this UCB 


TCB address of attached task 


Table 3-3 
Required SCB Fields 


I/O queue listhead 

Priority of interrupting source 
Interrupt vector address divided by 4 
Initial timeout count 


Controller index (that is, controller number 
multiplied by 2) 


Controller status 


Address of control and status register 


Fork block 


S.MPR Mapping register block; needed only by UNIBUS NPR 
devices running on DP-11 processor that employs 
extended-addressin is) mode 


TA LS lke DR mus, SVwwoai 
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3.2 USER-WRITTEN LOADABLE DRIVERS 


In deciding whether the data base for your loadable driver should be 
resident or loadable, consider the following characteristics of 
loadable data bases: 


e When you load a driver, the MCR/VMR LOA command checks to see 
whether a data base is resident for the type of device whose 
driver is being loaded. If a data base is not resident, the 
LOA command reads the driver symbol definition file to find 
the start and end of the data base in the driver image. 
(Thus, if your driver data base is to be loadable, you must 
have defined its start and end in the data base source code.) 
Knowing the Start and end, the LOA command reads the data base 
from the driver image. The LOA command places the data base 
in the system pool so that it resides in Executive address 
space, accordingly relocates pointers and links within the 
data base to be valid Executive addresses, and also connects 
DCB (s) in the data base to the system device tables. 
Moreover, the LOA command performs many consistency and 
validity checks on the data base being loaded so as to prevent 
the system device tables from being corrupted by an incorrect 
data base. 


e A loadable data base is only loaded once; thereafter, it is 
resident until the system is bootstrapped again. The UNL 
command does not remove a data base from memory even though 
the data base was loaded with the LOA command. 


e The LOA command relocates certain known pointers within the 

- control blocks.1 If the data base requires relocation of 
additional address pointers beyond the standard ones, it 
cannot be loaded with the LOA command. It must be 
incorporated into the system as a resident data base during 
system generation. 


During debugging of a loadable driver (with loadable data base), you 
can correct errors in the coding of the driver itself by unloading, 
modifying, assembling, task-building, and reloading the driver. 
However, if the data base must be replaced, the system must be 
bootstrapped to remove it. You can then modify, assemble, and 
task-build the data base, and reload it along with the (corrected) 
driver. 


The subsections below describe the procedure for incorporating a 
user-written loadable driver. 


3.2.1 Creating the Loadable Data Base and Driver Modules 


The general procedure for incorporating a loadable driver with a 
loadable data base is as follows: 


1. Complete SYSGEN Phase I and answer the appropriate questions 
that include the necessary driver support features in the 
Executive. Edit the assembly prefix file RSXMC.MAC and 
define a conditional symbol LDSxx for each loadable driver. 
See Section 3.1.1 for a discussion of system generation 
support. 


1. The pointers are: (DCB) D.LNK, D.UCB; (UCB) U.DCB, U.RED, U.SCB. 
(SCB) S.LHD+2. Chapter 4 gives details on these and other fields in 
the data base. 
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2. Complete SYSGEN Phase II. During Phase II you must edit 
RSXBLD.CMD, the Executive build command file (see Section 


3.3), and add the following line: 


GB LDEF=SUSRTB: 0 


(The symbol SUSRTB in the file [11,10]SYSTB.MAC defines the 


link word to a user-written driver's resident DCB. 


Adding 


this line forces the link word to be zero.) If you do not add 


this line when you do not have a resident data base, 


Builder generates an undefined symbol error when it 


the Task 


builds 


the Executive. However, you can disregard that error because 
the Task Builder sets the contents of the link word to Zero. 


3. After SYSGEN Phase II completes, you can manually build the 


driver. 


After completing these steps, you can assemble the driver and data 


base at any time. 


4. While both the loadable driver and its data base 


can be 


contained in the same Source module, it is recommended that 
you create separate sources for your driver and its data base 
and place them in UFD [11,10]. If, however, you place both 
the data base and the driver in the same module, you must 
ensure that, when linked, the data base follows the driver 
code. You can do this by physically placing the data base 
code after the driver code or by using .PSECT names to force 


proper allocation. 


5. A useful convention is to name your data base source xxTAB 
and your driver source xxDRV, where xx is the 2-character 


(alphabetic) device mnemonic. 


6. You must place the DCB first in the assembly source 


code of 


the driver data base module. In a multiuser protection 
system, the DCB must be followed first by the associated 
UCB(s) and then by the SCB(s). All UCB(S) associated with a 


particular DCB must be contiguous. DIGITAL-supplied 


drivers 


use this ordering scheme; see the file [11,10]SYSTB.MAC, 


created by Phase I of SYSGEN, for examples. Since 


you are 


creating a loadable data base for a Single driver, your 


source code will contain a single DCB with associated 


and SCB(s). 


7. The global label $xxDAT:: marks the start of your 


UCB (s) 


driver's 


data base (the DCB). The global label $xxEND:: marks the 
end of the data base (that is, immediately following’ the 
final word of the data base). These labels are absolutely 


required. The letters xx represent the 2-character 


mnemonic. 


To assemble your driver, set the default UIC to [11l,2x] and 
assembler as follows (user input underlined): 


>SET /UIC=[11, 2x] @ 
>MAC aD OOS 
MAC>xx DRV,xxDRV=LB: [1,1] EXEMC/ML, LB: [11, 10]RSXMC,xxDRV ED 


use the following input to MAC: 


Gi 


device 


run the 


MAC>xx TAB ,xxTAB=LB: [1,1]EXEMC/ML, LB: [11,10]RSXMC1,xxTAB €€) 
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Next, you use the following command to add both the driver and its 
data base to the Executive object module library: 


LBR>LB: [1, 2x] RSX11M/RP=[11, 2x] xxDRV, xxTAB f€) 


3.2.2 Task-Building a Loadable Driver 


In this section, two examples of task-building a loadable driver with 
a loadable data base are presented: one for a mapped system and one 
for an unmapped system. 


3.2.2.1 Task-Building a Loadable Driver on a Mapped System - The 
following seven requirements apply to task-building any loadable 
driver, whether usSer-written or DIGITAL-supplied. 


l. You must specify a task image file name and a_e symbol 
definition file name as TKB_ output. Both files must be 
placed in the UFD corresponding to the system UIC that will 
be in effect when the command is issued. The file names must 
both be xxDRV, where xx is the device mnemonic. The Task 
Builder produces output files named xxDRV.TSK and xxDRV.STB. 
For example, the beginning of input to TKB to build a 
Ppaper-tape reader driver for a mapped system might appear as 
follows (user input underlined): 


>T KB @ED 
TKB>[1,54]PRDRV/-HD/-MM, , [1,54] PRDRV= fED 
1 T ii 
Task image. Switches: see Symbol 
items 2 & 3 definition. 
below. 


2. You must not have a task header. Use the switch /-HD, as_ in 
the example above. A driver is not really a task but an 
extension of the Executive, and as such needs no task header. 


3. You must use the /-MM switch, whether in fact the driver is 
destined for a mapped or an unmapped system. 


4. You must link to the system symbol definition file that 
contains definitions of Executive global symbols. Continuing 
the paper-tape reader driver example referred to above, 
further TKB input might look like this: 


TKB>LB: [1, 24] RSX11M/LB: PRDRV: PRTAB £) 
TKB>[1,54]RSX11M.STB/SS ED 


The first line above specifies the library file (/LB) in 
which the input driver object module and the object file for 
the loadable data base can be _ found. The object module 
specification for the driver must always precede the 
specification for the data base in the TKB command line. 


You omit the data-base file specifier when task-building any 
DIGITAL-supplied driver or one of your own drivers if it has 
a resident data base. All DIGITAL-supplied drivers that are 
declared loadable at system generation use resident data 
bases. 


3. 2 2.2 
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The second line in item 4 above indicates that the symbol 
table file RSX11M.STB is to be searched selectively (/SS) for 
definitions of Executive global symbols. Note that the /SS 
Switch must appear in this context. It cannot be omitted. 


You must link to the system library file that defines masks 
and offsets used in the Executive. Continuing the example: 


TKB>LB: [1, 1] EXELIB/LB 
TKB>/ : 


The single slash begins the option phase of the Task Builder. 


The driver code will execute as a part of the Executive, and 
thus the driver will use the Executive stack. Therefore, you 
must direct the Task Builder not to allocate space for a 
stack within the driver, as follows: 


TKB >STACK=0 fe?) 


You must specify a partition for the driver. The 
specification differs for mapped and unmapped systems. 
Continuing the mapped-system example: 


TKB>PAR=DRVPAR: 120000: 4000 f&D 

TKB>// RED 

‘ Lf 
On mapped systems, the starting address of the partition must 
be 120000 octal. That is, the loadable driver must be mapped 
to kernel APR 5. 


On unmapped systems, the second parameter must be the 
physical starting address of the partition. 


On either mapped or unmapped systems, the length of the 
partition may not exceed 4K words (20000 octal bytes). 


The double slash terminates the Task Builder's input. 


Task-~Building a Loadable Driver on an Unmapped System - In 


the example below, we build a magtape driver for an unmapped system. 
The only differences from the mapped-system example are the partition 


starting 


address and the UFD of some of the files ([1,50] and [1,20] 


instead of [1,54] and [1,24], respectively). 


>TKB PED) 

TKB>[1,50]MTDRV/-HD/-MM, , [1,50]MTDRV= ED 
TKB>LB: [1, 20] RSX1IM/LB:MTDRV:MTTAB @en) 
TKB>[(1,50]RSX11M.STB/SS f&) 
TKB>LB: [1, 1] EXELIB/LB @en) 

TKB>/ @éM 

ENTER OPTIONS: @é 

TKB>STACK=0 fe) 

TKB >PAR=DRVPAR: 34000: 4000 fe) 

TKB>// GD 


> 
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3.2.3 Loading a User-Written Loadable Driver 
Loading is done by using the privileged MCR command LOA. Its form is: 
LOA xx: [/PAR=partition] 


where xx is the 2-character device mnemonic. Specifying a partition 
is optional. If none is specified, the partition input to the Task 
Builder is used. 


The LOA command requires that the two files xxDRV.TSK and xxDRV.STB 
reside under the system UFD (that is, the UFD established by the SET 
/SYSUIC command). Typically, this UFD is [1,50] for unmapped systems 
and [1,54] for mapped systems. 


LOA searches first for a resident data base for the driver being 
loaded. If none is found, LOA looks for the following global symbols 
in the symbol definition file xxDRV.STB: 


SxxDAT:: Address of the start of the data base (the DCB) 
associated with the driver 


SxxEND:: Addresst+2 of the last word of the data base 
associated with the driver 


3.2.4 Creating the Loadable Driver and Resident Data Base Modules 


If you decide upon a resident data base, you create the data base 
object module during SYSGEN Phase I. You use the Same procedure as 
that for a resident driver. 


To create the resident data base, follow the procedure described in 
Section 3.3 with the exception of initializing the device interrupt 
vector. Since there is only one resident data base module (USRTB, 
which contains all the resident data bases), you assemble the resident 
data bases for loadable drivers with the resident data bases for 
resident drivers. 

To assemble the loadable driver, use the following command to MAC: 


MAC>xxDRV, xxDRV=LB: [1,1]EXEMC/ML, LB: [11,10]RSXMC,xxDRV @e 


3.2.5 Building a Loadable Driver and Its Resident Data Base 
You build all resident data bases into the Executive as described in 
Section 3.3. You build the loadable drivers after the Executive is 
built. When SYSGEN asks the following question during Phase II: 

5. Driver 2-character device mnemonic [S]: 


enter the characters xx, where xx is the driver name. 


After your system is built, you can load your driver as described in 
Section 3.2.3. 
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3.3 USER-WRITTEN RESIDENT DRIVERS 


This section describes specific details for user-written resident 
drivers. 


l. Create the assembly source file for the resident data base in 
UFD [11,10]. Use USRTB.MAC as the file specification. USRTB 
as the file name is not actually required. It is, however, a 
useful convention -- aS reflected in the sample dialogue 
described below. 


2. There is no mandatory ordering of the different control 
blocks in the data base. for your resident driver. It is 
suggested that you follow the convention of placing the DCB 
first, followed by the UCB(s), followed by the SCB(s). 
However, it is required that all UCB(s) associated with a 
particular DCB must be contiguous. DIGITAL-supplied RSX-11M 
drivers use this ordering scheme; see the file [11,10] 
SYSTB.MAC, created by Phase I of SYSGEN, for examples. If 
you are incorporating multiple resident drivers into your 
system, you will have more than one instance of a DCB with 
UCB(s) and SCB(s). 


3. Initialize the device interrupt vector (refer to Section 
4.1.5 for a description of this process). 


4, Use the global label SUSRTB:: as the address of your first 
(or only) DCB. This is absolutely required. 


During Phase I, SYSGEN asks: 
25. Do you intend to include a user-written driver? [Y/N] 


If you answer Yes, then subsequent questions guide you through the 
process of adding the driver to the generated system. Refer to 
Section 3.1.1 for a discussion of system generation support and_ the 
questions asked. Operations performed include assembling the driver 
and its data structure, and editing the RSX-11M task-build command 
file. 


The following sample dialogue illustrates the addition of a _ resident 
driver for a PK: device. All user responses are underlined. After 
SYSGEN assembles the DIGITAL-supplied drivers, it prints some 
instructions, then pauses to allow you to assemble your driver(s), as 
follows: 


>; Assemble user-written driver (s) 


>F 
>? The following instructions apply to resident drivers and 
>3 loadable drivers with resident data bases. 
c 
: For loadable drivers, you must ensure that a symbol definition 
: of the format: 
>; LDS$xx=0 
>; (where xx is the device name) appears in the assembly prefix 
>; file [11,10]RSXMC.MAC for each loadable driver xxDRV. 


3=13 
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>? SYSGEN will now pause to allow you to assemble your drivers(s) 
a3 and USRTB module. Using a driver name xxDRV (where xx is 
>: the device name; for example, DK), you can type commands 
>; in the following format to assemble the driver and USRTB 
ae modules. 

>; 

>3 MAC 

>; MAC>xxDRV=LB: [1,1]EXEMC/ML, SY: [11,10]RSXMC,xxDRV 

> MAC>USRTB=LB: [1,1]EXEMC/ML, SY: [11,10]RSXMC,USRTB 

>; MAC>“Z 

AT. -- PAUSING. TO CONTINUE TYPE "RES ...AT." 

> 

>MAC 


MAC>PKDRV=LB: [1,1] EXEMC/ML, SY: [11,10]RSXMC, PKDRV ep 
MAC>USRTB=LB: [1, 1] EXEMC/ML, SY: [11, 10] RSXMC, USRTB fp 
MAC > Giri) 

> 

>RES ...AT. fe) 


AT. -- CONTINUING 
> 
After you exit from MACRO-11 and type the command to resume, SYSGEN 


finishes Phase I. 


When you start Phase II, SYSGEN asks a few questions, prints some 
instructions, and pauses for you to build the driver(s) as follows: 


>; 

>; Build user-written driver (s) 

>? 

>; You must now edit the Executive build command file RSXBLD.CMD 

Par to include your user-written driver and data base in your system. 
>F 

>: If you are including a resident data base, locate the line 

>: in which the module SYSTB is referenced and add :USRTB 

>} immediately after it, for example: 

>; LB: [1, 24]RSX11M/LB:SYSTB: USRTB:SYTAB: INITL, LB: [1,1]EXELIB/LB/SS 
>? If you are not including a resident data base, add the line 

>; GBLDEF=SUSRTB: 0 

>? to the file instead. 

>; 

>: For each resident driver, add a line of the form: 

>; LB: [1,24]RSX11M/LB:xxDRV 

>? where other drivers are referenced (where xx is the device name, 
> for example DK). 

>? NOTE: For each loadable driver, do not add a corresponding 

>; line to the build command file 

>i 

»G SYSGEN will now pause to allow you to edit RSXBLD.CMD. 

>; After you exit from the editor and resume, SYSGEN builds the 

>: Executive and drivers. 

AT. -- PAUSING. TO CONTINUE TYPE "RES ...AT." 


>EDI RSXBLD.CMD®ED 

[00028 LINES READ IN] 

[PAGE 1] 

*L SYSTBRED 

LB: [1, 24]RSX11M/LB:SYSTB:SYTAB: INITL, LB: [1,1]EXELIB/LB/SS 
*C /SYSTB:/SYSTB: USRTB: /ep 
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LB: [1, 24]RSX11M/LB:SYSTB: USRTB:SYTAB: INITL, LB: [1,1]EXELIB/LB/SS 
*L DYDRV PED 

[ *EOB*] 

*T RED 

*L DYDRV 7 

LB: [1, 24]RSX11M/LB: DYDRV 

* T RET) 

LB: [1, 24]RSX11M/LB: PKDRV 


*EX GED 
[EXIT] 


>RES ...AT.RED 


AT. -- CONTINUING 


After you perform the indicated operations and type the command _ to 
continue with SYSGEN, the Executive is built and you are given a 
chance to build any loadable drivers as follows: 

>; Build Loadable drivers 

>* 4, Build all selected loadable drivers into DRVPAR? [Y/N]:Y 

>; You can now build your uSer-written driver (if it is a loadable 

>; driver). If you choose not to build it now, or it is not loadable 
>; strike carriage return in response to the next question. 

>; When all drivers are built, strike carriage return 

>* 5. Driver 2-character device mnemonic [S]: 


When Phase II completes, your resident driver is incorporated in the 
Executive and is ready to run. 


3.4 DRIVER DEBUGGING 
Because the protection checks provided for user programs are not 
available to system modules, driver errors are more difficult to 
isolate than user-program errors. But conventional drivers, because 
they are modular and_= short, probably can be easily debugged. This 
debugging process requires that you understand the following topics, 
each of which is discussed in a separate subSection: 

e Debugging aids and tools 

e Fault isolation 

e Fault tracing 


e Rebuilding and reincorporating a driver 


INCORPORATING USER-WRITTEN DRIVERS INTO RSX-11M 


3.4.1 Debugging Aids 


Adding a user-written driver carries with it the risk of introducing 
obscure bugs into an RSX-11M system. Since the driver runs as part of 
the Executive, special debugging tools are both desirable and 
necessary. RSX-11M provides several such aids, which can be 
incorporated into your system during system generation: 


e Executive stack and register dump 

e xXDT 

e Panic dump 

e Crash Dump Analyzer (CDA) support routine. 


You need not select any of this software during system generation. 
If, however, you do require the facilities they offer, you can select 
from one to three of them for incorporation in your system (panic dump 
and the CDA support routine are mutually exclusive). The following 
subsections describe the features and use of each debugging aid. 


3.4.1.1 Executive Stack and Register Dump Routine - At system 
generation, you can indicate that you want a dump of the Executive 
stack and the registers when a crash occurs. If you choose this 
option, the system will perform as follows: 


l. A system error, or the XDT X command (described in the next 
section), or operator manipulation of the switch register 
following a CPU halt, will cause processing to resume at 
location 40(octal). 


2. Location 40(octal) contains a JMP instruction that causes the 
Executive to execute the code beginning at location $CRASH. 


3. SCRASH invokes the routine that dumps the Executive stack and 
registers as shown below: 


SYSTEM CRASH AT LOCATION 047622 
REGISTERS 

RO=000340 R1=177753 R2=000353 R3=000000 
R4=000004 R5=046712 SP=000472 PS=000340 
SYSTEM STACK DUMP 

LOCATION CONTENTS 


000472 000004 
000474 000000 
000476 001514 
000500 000340 
000502 LITTS3 
000504 000353 
000506 000000 
000510 000000 
000512 057750 
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000514 002504 
000516 030011 
000520 100340 
000522 000340 
000524 056446 
000526 000000 
000530 102144 
000532 000000 
000534 101376 
000536 101372 
000540 102022 
000542 170000 


Following this display, either the CDA support routine or panic dump 


is invoked, depending on which (if either) is preSent in the system. 
Otherwise, the system halts. 


3.4.1.2 XDT - The Executive Debugging Tool - An interactive debugging 
tool has been developed for RSX-11M to aid in debugging Executive 
modules, I/O drivers, and interrupt service routines. This debugging 
aid, called XDT, is a version of the RSX-11 Octal Debugging Tool 
(ODT). XDT does not contain the following features and commands 
available on ODT: 

No $M - (Mask) register 

No $X - (Entry Flag) registers 

No $V - (SST vector) registers 

No $D - (I/O LUN) registers 

No SE - (SST data) registers 


No SW - (Directive Status Word) $DSW word 


No E - (Effective Address Search) command 
No F - (Fill Memory) command 

No N - (Not word search) command 

No V - (Restore SST vectors) command 

No W - (Memory word search) command 


In addition, the X (Exit) ODT command has been changed for XDT. The X 
command causes a jump to the crash-reporting routine. 


Except for the omitted features and the change in the X command, XDT 


et 


is command-compatible with RSX-11 ODT; consequently, the IAS/RSX-11 
ODT Reference Manual can be used as a guide to XDT operation. 


XDT may be included in a system during Phase I of SYSGEN. The 
following question is asked: 


*30. Executive Debugging Tool (XDT)? [Y/N]: 
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If you answer Yes, then XDT is automatically included in the generated 
system. When the resultant system is bootstrapped, XDT takes control 
and types on the console terminal: 


XDT: <system version> 
followed by the prompting symbol 
XDT> 


You can set breakpoints at this time, and then type the G command, 
passing control to the RSX-1lIM Executive initialization code. 
Whenever control reaches a breakpoint, a printout similar to that 
produced by RSX-11 ODT occurs. 


You can initiate a forced entry to XDT at any time from a _ privileged 
terminal by means of the MCR BRK (breakpoint) command. Thus, the 
normal procedure is to type G when the system is bootstrapped without 
setting any breakpoints. When it becomes necessary to use XDT, the 
MCR BRK command is executed, causing a forced breakpoint. XDT then 
prints on the console terminal: 


BE:xxxxxx 
followed by the prompting symbol 
XDT> 


You can then set breakpoints and/or issue other XDT commands. 
Continue system operation by typing the P (proceed) command to XDT. 


Note that XDT runs entirely at priority level 7 and does not interfere 
with user-level RSX-11 ODT. In other words, user-level RSX-1l1 ODT can 
be in use with several tasks, while XDT is being used to debug 
Executive modules. 


All XDT command I/O goes to and from the console terminal, and the L 
(List Memory) command can list on either the console or the line 
printer. 


Using XDT to debug a loadable driver on a mapped system has_ special 
pitfalls. One problem that can arise is a T-bit error: 


TE:xxxxXxxX 
XDT> 


This error results when control reaches a breakpoint that you have 
set, using XDT, in a loaded driver on a mapped system. The T-bit 
error, rather than the expected BE: error, occurs unless’ register 
APR5 is mapped to the driver at the time XDT sets the breakpoint. 


To avoid this T-bit error, assemble the driver with an embedded BPT 
instruction, or use either the ZAP utility or the MCR OPE command to 
set the breakpoint by replacing a word of code with the BPT 
instruction. When control reaches a breakpoint set in this manner, 
XDT prints: 


BE:xxxxxx 
XDT> 
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Recover as follows: Using XDT, replace the BPT instruction with the 
desired instruction. Decrement the PC by subtracting 2 from the 
contents of register R7. Then proceed by using the P or S commands. 


NOTE 


You should not set breakpoints in more 
than one module that maps into the 
Executive through APR 5 or APR 6. In 
Particular, do not set breakpoints in 
more than one loadable driver at a time 
or XDT will overwrite words of main 
memory when it attempts to restore the 
contents of breakpoints. 


3.4.1.3 Panic Dump - The Panic Dump routine saves’ registers RO 
through R6 and then halts, awaiting dump limits to be entered. 


The procedure for entering dump limits depends on whether your 
processor has a console switch register. The subsections that follow 
describe the procedure in each instance. 


3.4.1.4 Using the Panic Dump Routine on Processors with Console 
Switch Registers - For processors with console switch registers, you 
can obtain dumps of selected blocks of memory by using the _ following 
procedure: 


1. Enter the low dump limit in the console switch register and 
press CONT. The processor will immediately halt again. 


2. Enter the high dump limit in the console switch register and 
press CONT. The dump will begin on the device whose CSR 
address is DSSBUG (usually 177514, which is’ the line 
printer). The actual value of DSSBUG is determined during 
system generation when answering the panic dump question. At 
the end of the dump, the processor will again halt, awaiting 
the input of another set of dump limits. 


If your system does not have the Executive routine stack and 
register dump, enter the dump limits 0-520(octal) when the 
Panic Dump routine first halts. This causes dump of the 
system stack and the general registers. The limit 520(octal) 
changes if the highest interrupt vector is above 400(octal). 
The actual upper limit is always the value of the global 
symbol $STACK and can be obtained from the global symbol 
listing in the Executive memory allocation map. 


3.4.1.5 Using the Panic Dump Routine on Processors Without Console 
Switch Registers - A number of PDP-1l processors are being delivered 
without a console switch register; they are configured with the M9301 
Console Emulator and Bootstrap. This presents no problem for the 
normal operation of RSX-11M, because it does not require a switch 
register. However, the Panic Dump Routine usually reads its arguments 
from the switch register. In systems that have been generated for 
Processors that have no_ switch register, the panic dump module has 


oa 
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been altered to read its arguments from location 0. The following 
instructions are designed to allow you to enter the proper information 
to the Panic Dump Routine on processors equipped with the M9301 
Console Emulator. 


1. When the Panic Dump Routine halts, the RUN light will go out. 
At this time press and release the BOOT switch. 


The Console Emulator should display: 


XXXXXX XXXXXX XXXXXX nnnnnn 
$ 


where nnnnnn is the address+2 of the HALT instruction. 
2. You should enter the following: 


SL_0 fe?) 
SD_low-address fe 
SL nnnnnnfen 


SS Ge 


3. The processor should again halt. Press and release the BOOT 
switch. 


The Console Emulator should display: 


XXXXXX XXXXXX XXXXXX mmmmmm 
$ 


4. You should then enter: 


SL_0 Ge? 
SD high-address@é 
$L_mmmmmmey 


SS GD 


At this time the dump should commence. When it is finished, the 
processor will halt and wait for additional input. 


3.4.1.6 Sample Output from Panic Dump - A portion of the output from 
Panic Dump is’ shown below. Output is in 3-line groupings. In the 
left-hand column, two addresses are shown. The first address is the 
absolute address; the second address is the dump relative address. 
The first line in a 3-line group gives the octal word value; the 
second line gives the two octal byte values of the word; the third 
line contains the ASCII representation of the bytes. The ASCII 
representations in each word are reversed to improve readability. The 
first output grouping from Panic Dump shows, proceeding from left to 
right, the address/absolute address, PS, RO, Rl, R2, R3, R4, R5, and 
the SP. 


000544 000000 046076 000066 000000 000000 000000 000000 045316 
000000 000 000 114 076 000 066 000 000 000 000 000 000 000 000 112 316 
“e “*@ > L 6 “@ “@ “@ “@ “@ “@ “*“@ “*“@ “*@ N J 


000000 022646 000340 045770 000340 045770 000340 045770 000340 
000000 045 246 000 340 113 370 000 340 113 370 000 340 113 370 000 340 
& % “@ K “@ K “@ K “@ 
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000020 045776 000340 011124 000340 045770 000340 050500 000340 
000020 113 376 000 340 022 124 000 340 113 370 000 340 121 100 000 340 
K PG aR SR “@ K “@ @ Q “@ 


000040 000167 000543 000001 000001 000000 000000 000000 000353 
000040 000 167 001 143 000 001 000 001 000 000 000 000 000 000 000 353 


000060 035444 000340 034034 000340 032776 000340 032402 000340 
000060 073 044 000 340 070 034 000 340 065 376 000 340 065 002 000 340 
Si “@ “\ 8 “@ 5 “@ “B 5 “@ 


3.4.1.7 Crash Dump Analyzer Support Routine - The Crash Dump Analyzer 
(CDA) support routine, when entered, prints the following message on a 
notification device specified at SYSGEN: 


CRASH — CONT WITH SCRATCH MEDIA ON device mnemonic 


You can then put the secondary crash dump device on line and depress 
the CONT switch on the operator's console. The Executive Crash Dump 
routine will dump memory to the crash dump device and halt the 
Processor upon completion. 


The procedure for subsequently invoking the Crash Dump Analyzer, which 


reads and formats the memory dump, is fully documented in the RSX-11M 
Crash Dump Analyzer Reference Manual. 


3.4.2 Fault Isolation 
Four causSes can be identified when the system faults: 


e A user-state task has faulted in such a way that it causes the 
system to fault. 


e The user-written driver has faulted in such a way that it 
causes the system to fault. 


e The RSX-11M system software itself has faulted. 

e The host hardware has faulted. 
When the system faults, you must immediately determine which of these 
four causes is’ responsible. This section presents some procedures 


that can help you isolate the source of the fault. Correcting the 
fault itself is your responsibility. 


3.4.2.1 Immediate Servicing - Faults manifest themselves in roughly 
four ways (they are listed here in order of increasing difficulty of 
isolation): 


1. If XDT is included, an unintended trap to XDT occurs. 


2. The system displays text indicating a crash has occurred and 
haits. 
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3. The system halts but displays nothing. 
4. The system is in an unintended loop. 


The immediate aim, regardless of the fault manifestation, is to get to 
a point where you can obtain pertinent fault isolation data. 


The following discusssions assume the existence of a system built with 
at least one of the debugging aids described in Section 3.4.1. (Note 
that the minimal system does not have space for these routines.) 


Case 1--The system has trapped to XDT: 


The trap may or may not be intended (for example, a previously set 
breakpoint). If it is not intended, type the X command, causing XDT 
to exit to location 40(octal), from which the Executive stack and 
register dump routine (if present), followed by either Panic Dump or 
the CDA support routine (if present), will be invoked. If, however, 
you have some idea of the source of the problem (for example, a recent 
coding change), then you can use XDT to examine pertinent data 
structures and code. 


Case 2--The system has displayed text indicating a crash has occurred: 


If the text consists of output from the Executive stack and _ register 
dump routine (refer to Section 3.4.1.1), all the basic information 
describing the state of the system has been displayed. If the text 
has been produced by the CDA support routine, follow the procedure for 
obtaining and formatting a memory dump as outlined in the RSX-11 Crash 


—_——_ 


Case 3--The system has halted but displays no information: 


Before taking any action, preserve the current PS and PC and the 
pertinent device registers (that is, examine and record the 
information these registers contain). The procedure depends on_ the 
particular PDP-1l processor. Consult the PDP-11 Processor Handbook 
for details. 


After preserving the PS and PC, invoke your resident debugging aid: 
enter 40(octal) in the switch register, press LOAD ADDR, and then 
press START. The contents of 40(octal) cause the successive 
invocation of: 

1. The Executive stack and register dump routine (if present) 

2. Either Panic Dump or CDA support routine (if present) 
Case 4--The system is in an unintended loop: 
Proceed as follows: 


1. Halt the processor. 


2. Record the PC, the PS, and any pertinent device registers, as 
in case 3 above. 


You may then want to step through a number of instructions in an 
attempt to locate the loop. For this attempt to be meaningful you 
must first disable the system clock. Proceed as follows: Examine the 
contents of word 777546 (if your system has a line-frequency clock) or 
word 772540 (if it has a programmable clock). Clear bit 6 in this 
word and redeposit the word. 


3=22 
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NOTE 


The system will not run until you have 
reenabled the clock. 


After trying to locate the loop and reenabling the clock, transfer to 
location 40(octal), as in case 3. 


3.4.2.2 Pertinent Fault Isolation Data - Before you attempt to locate 
the fault, you should dump system common (SYSCM). SYSCM contains a 
number of critical pointers and listheads. Find the appropriate 
limits for the module SYSCM by examining the Executive memory 
allocation map. Enter these limits to the Panic Dump routine or 
specify them in the command line used to invoke the Crash Dump 
Analyzer. 
In addition, you should dump the dynamic storage region and the device 
tables. The dynamic storage region is the module INITL and any 
additional space gained from the SET /POOL command and the device 
tables are in SYSTB. 
At this point, you have the following data: 

e Processor Status Word (PSW) 

e Program counter (PC) 

e Stack 

e RO through R6 

e Pertinent device registers 

e Dynamic storage region (pool) 

e Device tables 


e System common 


These data are the minimum required for effectively tracing the fault. 


3.4.3 Fault Tracing 


Three pointers in SYSCM are critical in fault tracing. These pointers 
are described below: 


SSTKDP - Stack Depth Indicator 
This data item indicates which stack was being used at the time 
of the crash. SSTKDP plays an important role in determining the 
origin of a fault. The following values apply: 


+1--User (task-state) stack 


0 or less--System stack 
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If the stack depth is +l, then the user has crashed the system. 
In a system with "brickwall" protection (for example, the mapped 
RSX-11M system), the nonprivileged user should not be able to 
crash the system. 


STKTCB - Pointer to the current Task Control Block (TCB) 
This is the TCB of the user-level task in control of the CPU. 
SHEADR - Pointer to the current task header. 


The $HEADR word points to the header of the task currently 
running. The task header provides additional data to help 
isolate a fault. Figures 3-1 and 3-2 show the layout of task 
headers for unmapped and mapped systems, respectively. 


The first word in the header is the user's stack pointer (SP) the 
last time it was saved. If the user branches wildly into the 
Executive, the Executive terminates the user task, but the system 
continues to function (possibly erroneously). Knowing the user's 
stack pointer provides one more link in the chain that may lead 
to the resolution of the fault. 


The header (aS pointed to by SHEADR) also contains the last-saved 


register set, just before the header guard word (the last word in 
the header--pointed to by H.GARD). 


H.HDLN 


Figure 3-1 Task Header on an Unmapped System 


Z2K-215-81 
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See res 


ZK-216-81 


Figure 3-2 Task Header on a Mapped System 


3.4.3.1 Tracing Faults Using the Executive Stack and Register Dump - 
To trace a fault after a display of the Executive stack and register 
contents, first examine the system stack pointer. Usually an 
Executive failure is the result of an SST-type trap within the 
Executive. If an SST does occur within the Executive, then the origin 
of the call on the crash-reporting routine is in the SST service 
module. (The crash call is initiated by issuing an IOT at a_e stack 
depth of zero or less.) 


A call to crash also occurs in the Directive Dispatcher when an EMT is 
issued at a stack depth of zero or less, or a trap instruction is 
executed at a stack depth of less than zero. The stack structure in 
the case of an internal SST fault is shown in Figure 3-3. 
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R5 
Return to system exit 
Zero or more SST parameters 


SST fault code 
Number of bytes 


<—_____—- 5p 
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Figure 3-3 Stack Structure: Internal SST Fault 


The fault codes are: 


0 ;ODD ADDRESS AND TRAPS TO 4 

2 ;MEMORY PROTECT VIOLATION 

4 ;BREAK POINT OR TRACE TRAP 

6 ;I1OT INSTRUCTION 

10 ; ILLEGAL OR RESERVED INSTRUCTION 
A? ;NON RSX EMT INSTRUCTION 

14 ;TRAP INSTRUCTION 

16 711/40 FLOATING POINT EXCEPTION 
20 7;SST ABORT-BAD STACK 

22 ;AST ABORT-BAD STACK 

24 ;ABORT VIA DIRECTIVE 

26 ;TASK LOAD READ FAILURE 

30 7TASK CHECKPOINT READ FAILURE 
32 ;TASK EXIT WITH OUTSTANDING I/0 
34 ;TASK MEMORY PARITY ERROR 


The PC points to the instruction following the one that caused the SST 
failure. The number of bytes is the number normally transferred to 
the user stack when the particular type of SST occurs. If the number 
is 4, then a non-normal SST fault occurred, and only the PSW and PC 
are transferred. There are no SST parameters. 


If the failure is detected in $DRDSP, the stack is the same as that 
Shown in Figure 3-3, except that the number of bytes, the SST fault 
code (the fault codes are listed above), and the SST parameters are 
not present. The crash report message, however, will indicate that 
the failure occurred in SDRDSP. 
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One SST-type failure, stack underflow, does not result in the _ stack 
structure of Figure 3-3. To determine where the crash occurred, first 
establish the stack structure; this can be deduced by the value of 
the SP and the contents of the top word on the stack. If the stack 
structure is that of Figure 3-3, then the failure occurred in S$DRDSP, 
or waS anormal SST crash. If the stack structure is that of Figure 
3-4, then an abnormal SST crash has occurred. 


<——_____-_ P 
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Figure 3-4 Stack Structure: Abnormal SST Fault 


Abnormal SST failures occur when it iS not possible to push 
information onto the stack without forcing another SST fault. When 
this situation occurs, a direct jump to the crash-reporting routine is 
made, rather than an IOT crash. The PS and PC on the stack are those 
of the actual crash, and the address printed out by the 
crash-reporting routine is the address of the fault rather than the 
address of the I0T that crashes the system. Note that the 
crash-reporting routine removes the PC and PSW of the IOT instruction 
from the stack, which in this case is incorrect. Thus, the SP appears 
to be four bytes greater than it really is (as in Figure 3-4). 


You now have all the information needed to isolate the cause of the 
failure. From this point on, rely on _ personal experience and a 
knowledge of the interaction between the driver and the _ services 
provided by the Executive. 


3.4.3.2 Tracing Faults When the Processor Halts Without Display - To 
trace a fault when the processor halts but displays no information 
(case 3 in Section 3.4.2.1 above), first examine $STKDP, S$TKTCB, and 
SHEADR. The difficulty in tracing failures in this case is that the 
system stack is not directly associated with the cause of a failure. 


By examining SSTKDP, you can determine the system state at the time of 
failure. If it was in user state, the next step is to examine the 
user's stack. The examination focuseS on Scanning the stack for 
addresses that may be subroutine links that can ultimately lead to a 
thread of events isolating the fault. This is essentially the aim of 
looking at the system stack if S$STKDP is zero or less. 


Frequently, a fault can occur that causes the SP to point to the top 
of the stack plus 4. This fault results from issuing an RTI 
instruction. The top two items on the stack are data. The result is 
a wild branch and then, most probably, a halt. Figure 3-5 shows a 
case in which two data items are on the stack when the program 
executes an RTI instruction. The top of the stack points to a word 
containing 40100(octal). If location 40100(octal) contains a HALT 
instruction, the original SP is four bytes below the final SP, and 
fault tracing should begin from the original SP. 
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Figure 3-5 Stack Structure: Data Items on Stack 


This type of fault also occurs when an RTS instruction is executed 
with an inconsistent’ stack. However, in that case, SP points to 
TOS+2. 


A scan of the contents of the general registers may give some hint as 
to the neighborhood in which a fault (or the sequence of events 
leading up to the fault) occurred. 


If the fault occurred in a new driver, a frequent source of clues is 
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT), 
as are the activity flags (US.BSY and S.STS). Other locations in both 
the UCB and SCB may also provide information that may help locate the 
source of the fault. 


3.4.3.3 Tracing Faults After an Unintended Loop - To trace a fault 
when an unintended loop has occurred, first halt the processor. 


After you halt the processor, the same state exists as was discussed 
in Section 3.4.3.2. Follow the same tracing procedure described 
there. A specific suggestion is to check for a stack overflow loop. 
Patterns of data successively duplicated on the stack indicate a stack 
looping failure. 


3.4.3.4 Additional Hints for Tracing Faults - Another item to check 
is the current (or last) I/O packet, the address of which is found in 
S.PKT of the SCB. The packet function (I.FCN) defines the last 
activity performed on the unit. 


If trouble occurred in terminating an I/0 request, a scan of the 
System dynamic memory region may provide some insight. This region 
Starts at the address contained in $CRAVL, a cell in SYSCM. Because 
all I/O packets are built in system dynamic memory, their memory is 
returned to the dynamic memory region when they are _ successfully 
terminated. Following the link pointers in this region may reveal 
whether I/O completion proceeded to that point. In systems with QIO 
optimization, $PKAVL (SYSCM) points to a list of I/O packet-sized 
blocks of dynamic memory that are not linked into the $CRAVL chain. 


A frequent error for an interrupt-driven device is to terminate an I/0 
Packet twice when the device is not properly disabled on I/0 
completion and an unexpected interrupt occurs. This action ultimately 
Produces a double deallocation of the same packet of dynamic memory. 
Double deallocation of a dynamic buffer in RSX-11M causes a loop in 
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the module $DEACB on the next deallocation (of a block of higher 
address) after the second deallocation of the same block. At that 
time, R2 and R3 both contain the address of the I/O packet memory that 
has been doubly deallocated. If XDT has been included in the system, 
the deallocation routine checks for bad deallocation and crashes’ the 
system if it occurs. 


3.4.4 Rebuilding and Reincorporating a Driver 


The procedure for rebuilding and reincorporating a driver into your 
system depends on whether the driver is resident or loadable. The two 
subsections that follow describe the procedure for each kind of 


driver. 


3.4.4.1 Rebuilding and Reincorporating a Resident Driver -— The 
procedure for rebuilding and reincorporating a resident driver 
involves four steps: 


NOTE 
In the examples that follow: 


e x (as in [11,2x] is equal to 0 
for unmapped systems and 4 for 
mapped systems 


e xxDRV is the name of the driver 
you are rebuilding or 
reincorporating 


1. Correct and assemble the driver and/or device data 
structures. 


Assuming that the object system has been bootstrapped, 
appropriate volumes have been mounted, and the source code 
for the user driver and/or device data base has been updated, 
then the following commands effect the reassembly of both the 
driver and the data base: 


>SET /UIC=[11, 2x]. 

>RUN SMAC@ED 

MAC>xxDRV=LB: [1, 1] EXEMC/ML, SY: [11, 10] RSXMC,xxDRV & 
MAC>USRTB=LB: [1, 1] EXEMC/ML, SY: [11, 10] RSXMC, USRTB@ED 
MAC >@RLD) 


2. Update the Executive object module library. 


After reassembling the user driver and/or data base, you must 
update the Executive object module library. The following 
commands will accomplish this: 


>SET /UIC=[1, 2x] 


>RUN SLBR @éy) 


LBR>LB : RSX11M/RP=[11, 2X] xxDRV, USRTBFED 
LBR>€RLZ) 
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3. Do Phase II of SYSGEN to rebuild the driver with the 
Executive. 


4. Bootstrap the new system. 


The new system can now be bootstrapped with the MCR BOO 
command. If you are using the baseline system, first issue 
the following command: 


>INS BOO; -—1eD) 
Then issue the following command: 


>BOO [1,5x]RSX11M Ee) 


3.4.4.2 Rebuilding and Reincorporating a Loadable Driver - A loadable 
driver is easier to reincorporate during debugging than a resident 
driver. After correcting and assembling the driver source, simply 
unload the old version, using the MCR UNL command, task-build the new 
one, and load it using the LOA command. 


The data structure, once loaded, becomes a permanent part of the 
Executive. It is not removed by the UNL command. If the data 
Structure is in error and cannot be patched, correct its source, 
reassemble, and task-build it. Then bootstrap the system before 
loading the corrected driver. 


CHAPTER 4 


WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS 


In Chapter 2, overviews were given for: 

e Data structures 

e Executive services 

@ Programming protocol 
This chapter gives details for the data structures, and in addition 
discusses specifics of multicontroller drivers and the INTSVS macro. 
Executive services are covered in Chapter 5. The protocol coverage in 


the discussion of programming protocol in Chapter 2 is detailed enough 
to make further elaboration unnecessary. 


4.1 DATA STRUCTURES 


The following elements in the I/O data structure are of concern to the 
programmer writing a driver: 


e I/0 packet 


e DCB 
e UCB 
e SCB 


e Device interrupt vector 


The I/O data structure, and the first four control blocks listed above 
in particular, contain an abundance of data pertaining to input/output 
operations. Drivers themselves are involved with only a subset of the 
data. 


In the detailed descriptions of the I/O packet, the DCB, the UCB, and 
the SCB that follow, most data fields (words or bytes) are classified 
by one of five descriptions. Two items in each description indicate: 


e Whether the field is initialized in the data structure source 


e What sort of access the driver has to the field during 
execution 
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The five descriptions are: 


<initialized, not referenced> 
Field is supplied in the data structure source code, and is 
not referenced by the driver during execution. 


<initialized, read-only> 
Field is supplied in the data structure source code, and may 
be read by the driver. 


<not initialized, read-only> 
Either an agent other than the driver establishes this field, 
or the driver sets it up once and thereafter references it 
read-only. 


<not initialized, read-write> 
Either the driver or some other agent establishes this field, 
and the driver may read it or write over it. 


<not initialized, not referenced> 
Field does not involve the driver in any way. 


These five descriptions cover most of the fields in the four’ control 
blocks described in this section. Exceptions are noted in the text. 


The final discussion in this section deals with the device interrupt 
vector. 


4.1.1 The I/O Packet 


Figure 4-1 shows the layout of the 18-word I/O packet, which is 
constructed and placed in the driver I/O queue by QIO directive 
processing, and is subsequently delivered to the driver by a call _ to 
SGTPKT. The DPB from which the I/O packet is generated is illustrated 
in Figure 4-2 (see Section 4.1.1.2). 


4.1.1.1 I/O Packet Details - The I/O packet is built dynamically by 
QIO directive processing. Thus, no static fields exist with respect 
to a driver. I/O packets are created dynamically, and therefore the 
first two descriptions in Section 4.1 (<initialized, not referenced> 
and <initialized, read-only>) do not apply. Fields in the I/O packet 
(described below) are classified as not referenced, read-only, or 
read-write. 


I.LNK 
Driver access: 
Not referenced. 
Description: 


Links I/O packets queued for a driver. A zero ends the 
chain. The listhead is in the SCB (S.LHD). 
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I. EFN 
Driver access: 
Not referenced. 
Description: 


Contains the event flag number as copied by QIO directive 
processing from the requester's DPB. 


LiNK 3 
I.PRI 7 
L.EFN 

1.TCB TCB address of requester 4 


: 


IL.PRM 24 


Device 
parameters 
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Figure 4-1 I/0 Packet Format 


I.PRI 


Driver access: 


Description: 


Priority copied from the TCB of the requesting task. 


I.TCB 
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Driver access: 


Read-only. 


Description: 


I.LN2 


TCB address of the requesting task. 


Driver access: 


Not referenced. 


Description: 


I.UCB 


Contains the address of the second word of the LUT entry in 
the task header to which the I/O request is directed. For 
open files on file-structured devices, this word contains the 
address of the window block; otherwise, it is zero. 


Driver access: 


Read-only. 


Description: 


I.FCN 


Contains the address of the unit to which I/0 is to be 
directed. I.UCB is the address of the Redirect UCB if the 
starting UCB has been subject to an MCR RED command. Used in 
cancel I/O routine to determine if the I/O request is from 
the task that is issuing the $IOKIL routine. 


Driver access: 


Read-only. 


Description: 


I. IOSB 


Contains the function code (see Table 4-1, Section 4.1.2.2) 
for the I/0 request. The modifier byte is one or more 
subfunction bits that may be set. 


Driver access: 


Not referenced. 


Description: 


I.IOSB contains the virtual address of the I/O Status Block 
(IOSB), if one is specified, or zero if one is not specified. 


I. IOSB+2 and I.IOSB+4 contain the address doubleword for the 
IOSB (See Appendix A for a detailed description of the 
address doubleword). On an unmapped system, the first word 
is zero; the second word is the real address of the IOSB. 


I.AST 


I. PRM 
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In a mapped system, the first word contains the relocation 
bias of the IOSB; the bias is, in effect, the number of the 
32-word block in which the IOSB starts. This block number is 
derived by viewing available real memory as a collection of 
32-word blocks numbered consecutively, starting with 0. 
Thus, if the IOSB starts at physical location 3210(octal), 
its block number is 32(octal). 


The second word is formatted as follows: 


Bits 0-5 Displacement in block (DIB) 
Bits 6-12 All zeros 
Bits 13-15 6 


k base. 


The displacement in block is the offset from th 
v9 arts at 


In the above example, in which the OSB s 
3210(octal), the DIB is equal to 10(octal). 


ra 


The value 6 in bits 13-15 is constant. It is used to cause 
an address’ reference through Kernel Address Page Register 6 
(APR6). Again, see Appendix A for details. 


Discussion of the address doubleword is deferred to an 
appendix because you seldom have to be concerned with its 


contents or format in writing a conventional driver. Its 
construction and subsequent manipulation are normally 
external to the driver. Subroutines are provided as 


Executive services for programmed I/O to render’ the 
Manipulations of I/O transfers transparent to the driver 
itself. 


Driver access: 


Not referenced. 


Description: 


Contains the virtual address of the AST service routine to be 
executed at I/O completion. If no address is specified, the 
field contains zero. 


Driver access: 


Not initialized, read-only. 


Description: 


Device-dependent parameters constructed from the last six 
words of the DPB. Note that if the I/0 function is a 
transfer (refer to the description of D.MSK in Section 
4.1.2.1), the buffer address (first DPB device-dependent 
parameter) is translated to an equivalent address doubleword. 
Therefore, device-dependent parameter n is copied to I.PRM 
+(2*(n-1))+2, where n is the number of the parameter and the 
first parameter is numbered Pl. 
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4.1.1.2 The QIO Directive Parameter Block (DPB) - The QIO DPB is 
constructed as shown in Figure 4-2. 
The parameters in the DPB have the following meanings. 
Length (required): 


The length of the DPB, which for the RSX-11M QIO directive is 
always fixed at 12(decimal) words. 


‘DIC (required): 


Directive Identification Code. For the QIO directive, this value 
is 1. For QIOW it is 3. 


Function Code (required): 


The code of the requested I/O function (0 through 31.). 


. 
: 
: 
: 
14 
Device- 

dependent 

parameters 
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Figure 4-2 QIO Directive Parameter Block (DPB) 


Modifier: 

Device-dependent modifier bits. 
Reserved: 

Reserved byte; must not be used. 
LUN (required): 

Logical Unit Number. 
Priority: 


Request priority. Ignored by RSX-11M. 


WRITING AN I/0 DRIVER--PROGRAMMING SPECIFICS 


EFN (optional): 


Event flag number. Zero indicates no event flag. If you specify 
no event flag, QIOWS directives are converted to QIOS directives. 


I/O Status Block Address (optional): 
This word contains a pointer to the I/O status block, which is a 
2-word, device-dependent, I/O-completion data packet formatted 
as: 
Byte 0 
T/O status byte. 
Byte 1 
Augmented data supplied by the driver. 
Bytes 2 and 3 
The contents of these bytes depend on the value of byte 0. 
If byte O equals 1, then these bytes usually contain the 
processed byte count. If byte 0 does not equal 0, then the 
contents are device-dependent. 
AST Address (optional): 
Address of an AST service routine. 
Device Dependent Parameters: 
Up to six parameters specific to the device and I/O function to 
be performed. Typically, for data transfer functions, the 
following four are used: 
e Buffer address 
e Byte count 
e Carriage control type 


e Logical block number 


The fields for any optional parameters not specified will be filled 
with zeros. 


4.1.2 The Device Control Block (DCB) 


Figure 4-3 is a schematic layout of the DCB. The DCB describes’ the 
static characteristics of a device controller and the units attached 
to the controller. All fields must be specified except D.PCB, which 
is required only if you selected the loadable-driver option. 
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4.1.2.1 DCB Details - The fields in the DCB are described below: 
D.LNK (link to next DcB)l 
Driver access: 
Initialized, not referenced. 
Description: 


Address link to the next DCB. A zero in this field indicates 
the last (or only) DCB in the chain. 


D.UCB (pointer to first UCB) 
Driver access: 


Initialized, not referenced. 


: 

; 

: 

Legal function mask bits 16. - 31. 24 

: 

No-op function mask bits 16. - 31. 30 

. 

D.PCB ! Address of partition control block 34 
Wee as ee ere ] 
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Figure 4-3 Device Control Block 


l. Parenthesized phrases indicate value to be initialized in the data 
base source code. 
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Description: 
Address link to the U.DCB field of the first, and possibly 
the only, UCB associated with the DCB. For a given DCB, ali 
UCBs are in contiguous memory locations and must all have the 
same length. 

D.NAM (ASCII device name) 

Driver access: 

Initialized, not referenced. 


Description: 


Generic device name in ASCII by which device units are 
mnemonically referenced. 


D.UNIT (unit number range) 
Driver access: 
Initialized, not referenced. 
Description: 
Unit number range for the device. This range covers’ those 
logical units available to the user for device assignment. 
Typically, the lowest number is zero, and the highest is n-l, 
where n is the number of device-units described by the DCB. 
D.UCBL (UCB length) 
Driver access: 
Initialized, not referenced. 
Description: 
The UCB can have any length to meet the needs of the driver 
for variable storage. However, all UCBs for a given DCB must 


have the same length. The specified length must include the 
following prefix words if any or all are present: 


e U.I0c 
e U.ERHL 
e U.ERHC 
e U.ERSL 
e U.ERSC 
e U.LUIC 
e U.OWN 
e U.CLI 
e U.MUP 
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D.DSP (dispatch table pointer) 
Driver access: 
Initialized, not referenced. 
Description: 
Address of the driver dispatch table. 


When the Executive wishes to enter the driver at any of the 
four entry points contained in the driver dispatch table, it 
accesses D.DSP, locates the appropriate address in the table, 
and calls the driver at that address. A zero table address 
indicates that the (loadable) driver is not in memory. For a 
loadable driver, then, this field must be initialized to 
zero. If the driver does not process a given function, then 
this address points to a return instruction within the 
driver's code. 


You must provide a driver dispatch table in the driver 
source. The label on this table is of the form $xxTBL; it 
must be a global label. The designation xx is the 
2-character generic device name for the device. Thus, STTTBL 
is the global label on the driver dispatch table for the 
generic device name TT. This table is an ordered, 4-word 
table containing the following entry points: 

e I/0 initiator 

e Cancel I/0 

e Device timeout 


e Power failure 


When a driver is entered at one of these entry points, entry 
conditions are as follows: 


At initiator: 


If UC. QUE=1 


R5 = UCB address 
R4 = SCB address 
Rl = Address of the I/O packet 


If UC. QUE=0 
R5 = UCB address 


Interrupts are allowed. (UC.QUE is a bit in U.CTL in the 
UCB. See Section 4.1.4.1.) 


At cancel I/0: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

Rl = Address of TCB of current task 
RO = Address of active I/O packet 


Device interrupts at or below the priority of the 
requesting device are locked out. 
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At device time-out: 


R5 = UCB address 

R4 = SCB address 

R3 = Controller index 

R2 = Address of device CSR 

RO = I/O status code IE.DNR (Device Not Ready) 


Device interrupts at or below the priority of the 
requesting device are locked out. 


At power failure: 


R5 = UCB address 
R4 = SCB address 
R3 = Controller index 


Interrupts are allowed. The power failure entry point of 
a loadable driver is called by LOA only for units that are 
on line and have UC.PWF set. 


D.MSK (function masks) 
Driver access: 
Initialized, not referenced. 
Description: 


There are eight words, beginning at D.MSK, that are critical 
to the proper functioning of a device driver. The Executive 
uses these words to validate and dispatch the I/O request 
specified by a QIO directive. Four masks, with two words per 
mask, are described by the bit configurations that you 
establish for these words: 


e Legal function mask 

e Control function mask 
e No-op function mask 

e ACP function mask 


The QIO directive allows for 32 possible I/O functions. The 
masks, aS stated, are filters to determine validity and I/0 
requirements for the subject driver. 


The Executive filters the function code in the I/O request 
through the four masks. The I/O function code is the 
high-order byte of the function parameter issued with the QIO 
directive. The decimal representation of that high-order 
byte is equivalent to the decimal bit number of the mask. If 
you want the function to be true in one of the four masks, 
you must set the bit in that mask in the position that 
numerically corresponds to the function code. For example, 
the code for I0.RVB is 21 (octal) and its decimal 
representation is 17. If you want IO.RVB to be true for a 
mask, you must set bit number 17(decimal) in the mask. 


The masks are laid out in memory in two 4-word groups. Each 
4-word group covers 16 function codes. The first 4 words 
cover the function codes 0-15: the second 4 words cover 


codes 16-31. Below is the layout used for the driver example 
in Section 6.2.2. 
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-WORD 140033 ; LEGAL FUNCTION MASK CODES 0-15. 
WORD 30 ;CONTROL FUNCTION MASK CODES 0-15. 
-WORD 140000 ;NO-OP FUNCTION MASK CODES 0-15. 
-WORD ;ACP FUNCTION MASK CODES 0-15. 


0 
eWORD 5 ; LEGAL FUNCTION MASK CODES 16.-31. 
e-WORD 0 ;CONTROL FUNCTION MASK CODES 16.-31. 
-WORD 1 ;NO-OP FUNCTION MASK CODES 16.-31. 
-WORD 4 ;ACP FUNCTION MASK CODES 16.-31. 


The mask words filter sequentially as follows: 
Legal Function Mask: 


Legal function values have the corresponding bit position in 
this word set to 1. Function codes that are not legal are 
rejected by QIO directive processing, which returns IE.IFC in 
the I/O status block, provided an IOSB address was specified. 


Control Function Mask: 


If any device-dependent data exists in the DPB, and this data 
does not require further checking by the QIO directive 
processor, the function is considered to be a control 
function. Such a function allows QIO directive processing to 
copy the DPB device-dependent data directly into the I/0 
Packet. 


No-op Function Mask: 


A no-op function is any function that is considered 
successful as soon as it is issued. If the function is a 
no-op, QIO directive processing immediately marks the request 
successful; no additional filtering occurs. 


ACP Function Mask: 


If a function. code is legal but specifies neither a _ control 
function nor a no-op, then it specifies either an ACP 
function or a transfer function. If a function code requires 
intervention of an Ancillary Control Processor (ACP), the 
corresponding bit in the ACP function mask must be set. ACP 
function codes must have a value greater than 7. 


In the specific case of read-write virtual functions, you 
have the option to set the corresponding mask bits. If the 
corresponding mask bits for a read-write virtual function are 
set, QIO directive processing recognizes that a file-oriented 
function is being requested to a non-file-structured device 
and converts the request to a read-write logical function. 


This conversion is particularly useful. Consider a 
read-write virtual function to a specific device: 


l. If the device is file structured and a file is open 
on the specified LUN, the block number specified is 
converted from a virtual block number in the file to 
a logical block number on the medium, and the request 
is queued to the driver as a_ read-write logical 
function. 
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2. If the device is file structured and no file is open 
on the specified LUN, then an error is returned and 
no further action is taken. 


3. If the device is not file structured, then the 
request is simply transformed to a read-write logical 
function and is queued to the driver. (Specified 
block number is unchanged.) 


Transfer Function Processing: 


Finally, if the function is not an ACP function, then by 
default it is a transfer function. All transfer functions 
cause the QIO directive processor to check the specified 
buffer for legality; {that is, inclusion within the address 
space of the requesting task) and proper alignment (word or 
byte). In addition, the processor checks the number of bytes 
being transferred for proper modulus (that is, nonzero and a 
proper multiple). 


Creating Mask Words: 
Creating function mask words involves five steps: 


1. Establish the I/O functions available on the device 
for which driver support is to be provided. 


2. Build the legal function mask: Check the _ standard 
RSX-11M function mask values in Table 4-1 for 
equivalencies. Only the POs KEG function is 
mandatory. IO.ATT and I0O.DET functions, if used, 
must have the RSX-11M system interpretation. DIGITAL 
Suggests that functions having an RSX-11M system 
counterpart use the RSX-11M code, but this is 
required only when the device is to be used in 
conjunction with an ACP. From the supported function 
list in Table 4-1, you can build the two legal 
function mask words. 


3. Build the control function mask by asking: 


Does this function carry a standard buffer address 
and byte count in the first two device-dependent 
Parameter words? 


If it does not, then either it qualifies as a control 
function, or the driver itself must effect the 
checking and conversion of any addresses to the 
format required by the driver. See Section 6.3 for 
an example of a driver that does this. (Buffer 
addresses in Standard format are automatically 
converted to address doubleword format.) 


Control functions are essentially those functions 
whose DPBs do not contain buffer addresses or counts. 
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4. Create the no-op function mask by deciding which 
legal functions are to be set aS no-ops. Typically, 
for compatibility with File Control Services (FCS) or 
Record Management Services (RMS) on 
non-file-structured devices, the file access/deaccess 
functions are selected as legal functions, even 
though no specific action is required to access or 
deaccess a non-file-structured device; thus, the 
access/deaccess functions are set to be no-ops. 


5. Finally, include the ACP functions Write Virtual 
Block and Read Virtual Block for those drivers that 
support both read and _ write. (Include only one 
related ACP function if the driver supports only read 
or write.) 


D.PCB (Partition Control Block) 
Driver access: 
Initialized, not referenced. 
Description: 


Address of the driver's Partition Control Block (PCB). This 
word is present in the DCB if and only if the loadable-driver 
SYSGEN option has been selected. It must be initialized to 
zero. You can extend the DCB by adding words after D.PCB. 


A PCB exists for every partition in a system. MCR creates a 
PCB when the SET /MAIN or SET /SUB commands are given. If a 
driver is loadable, its PCB describes the partition in which 
it resides. 


The Executive uses D.PCB together with D.DSP (the address of 
the driver dispatch table) to determine whether a driver is 
loadable or resident, and, if loadable, whether it is in 
memory. Zero and nonzero values for these two pointers have 
the meanings shown in Table 4-1. 


Table 4-1 
D.PCB and D.DSP Bit Definitions 


D.PCB: 


Loadabie 
=0 driver, Resident 
not in driver 
memory 
(not Loadable 
#0 possible) driver, 


in memory 
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4.1.2.2 Establishing I/O Function Masks - Table 4-2 is supplied to 
assist you in determining the proper values to set in the function 
masks. The mask values are given for each I/O function used by 
DIGITAL-supplied drivers. The bit number allows you to determine 
which mask group to use: for bits numbered 0 through 15, use the mask 
value for a word in the first 4-word group; for bits numbered 16 
through 31, use the mask value for a word in the second 4-word group. 


Table 4-2 
Mask Values for Standard I/O Functions 


Bit Mask Related I/O 


# Value Symbolic Function 


0 1 | peanee: I/O 

1 2 IO.WLB Write Logical Block 

2 4 TO. RLB Read Logical Block 

3 10 IO.ATT Attach Device 

4 20 IO0.DET Detach Device 

5 40 | paenera Device Control 
6 100 General Device Control 
i 200 General Device Control 
8 400 Diagnostics 

9 1000 IO. FNA Find File in Directory 
10 2000 IO.ULK Unlock Block 

11 4000 IO. RNA Remove File from Directory 
12 10000 IO. ENA Enter File in Directory 
13 20000 I0.ACR Access File for Read 
14 40000 IO. ACW Access File for Read/Write 
15 100000 IO.ACE Access File for Read/Write/Extend 
16 1 IO. DAC Deaccess File 

17 2 IO. RVB Read Virtual Block 

18 4 IO.WVB Write Virtual Block 

19 10 IO. EXT Extend File 

20 20 TO.CRE Create File 

21 40 IO.DEL Mark File for Delete 

22 100 IO.RAT Read File Attributes 

23 200 IO.WAT Write File Attributes 
24 400 IO. APC ACP Control 
25 1000 Unused 
26 2000 Unused 
27 4000 Unused 
28 10000 Unused 
29 20000 Unused 
30 40000 Unused 
31 100000 Unused 


Of the function mask values listed in Table 4-2, only I0.KIL is 
mandatory and has a fixed interpretation. However, if IO.ATT and 
IO.DET are used, they must have the standard meaning. (Refer to the 
RSX-11M/M-PLUS I/O Drivers Reference Manual for a description of 
Standard 1/O functions.) If QIO directive processing encounters a 
function code of 3 or 4 and the code is not set to be a no-op, QIOS 
assumes that these codes represent Attach Device and Detach Device, 


respectively. The other codes are suggested but not mandatory. You 
are free to establish all other function-code values on 
non-file-structured devices. The mask words must reflect the proper 


filtering process. 


If a driver 
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is being written for a file-structured device, 
standard function mask values of Table 4-2 must be established. 


Tables 4-3, 4-4, and 4-5 are guides to determining the 


masks for 4d 


proper 


the 


bit 


isks, tapes, and unit record devices (such as terminals, 
card readers, line printers, and paper tape puncheSsS/readers). 


Table 4-3 
Mask Word Bit Settings for Disk Drives 


Bit RSX-11M Related 
ia casita 
0 c c IO. KIL 
1 t t IO.WLB 
Z t t IO. RLB 
3 6 c IO. ATT 
4 c c IO. DET 
5 [0 STC 
6 
7 sa IO.CLN 
8 sd Diagnostic 
9 a IO.FNA 
10 a IO.ULK 
11 a IO.RNA 
12 a IO. ENA 
13 a n IO0.ACR 
14 a n IO. ACW 
15 a n IO. ACE 
16 a n IO. DAC 
iO a a IO. RVB 
18 a a IO.WVB 
19 a IO. EXT 
20 a IO.CRE 
21 a I0.DEL 
| 22 a IQ. RAT 
| 23 a I0.WAT 
24 a IO. APC 
| 25 
26 
| 27 
28 
29 
30 
oul 
t - transfer function, bit set only in legal 
function mask 
¢ - control function, bit set in legal and 
control function masks 
n - no-op function, bit set in legal and no-op 
function masks 
a - ACP function, bit set in legal and ACP 
function masks 
sa - special case, bit set only in ACP function 
mask, but not legal 
sd - special case, bit set only if diagnostic 


support in system and driver 
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Table 4-4 
Mask Word Bit Settings for Magnetic Tape Drives 


RSX-11M Related 


0 Cc Cc IO. KIL 
1 £ t IO.WLB 
2 t e IO. RLB 
3 c c TO, ATT 
4 c c TO. DET 
5 c c IO0.STC 
6 | Cc | Cc 
7 sa | I0.CLN 
8 sd | sd Diagnostic 
9 a IO. FNA 
10 | | IO.ULK 
11 | IO. RNA 
12 n | IO. ENA 
L3 a n IO. ACR 
14 a n IO. ACW 
15 | a | n I0.ACE 
16 a | n IO. DAC 
17 a a IO. RVB 
18 a a IO.WVB 
19 a IO. EXT 
20 a | IO.CRE 
21 | | IO.DEL 
22 | a IO. RAT 
23 IO.WAT 
24 | a | IO.APC 


transfer function, bit set only in legal function 
mask 

control function, bit set in legal and control 
function masks 

no-op function, bit set in legal and no-op 
function masks 

ACP function, bit set in legal and ACP function 
masks 

special case, bit set only in ACP function mask, 
but not legal 

special case, bit set only if diagnostic support 
in system and driver 
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Table 4-5 
Mask Word Bit Settings for Unit Record Devices 


Bit RSX-11M Related 


0 c IO. KIL 
1 t IO.WLB 
2 t IO. RLB 
3 Cc IO.ATT 
4 re IO.DET 
5 IO.STC 
6 
7 sa IO0.CLN 
8 sd Diagnostic 
9 a IO.FNA 
10 a I0.ULK 
Ed: a IO. RNA 
12 a I0. ENA 
13 a n IO0.ACR 
14 a n IO. ACW 
L5 a n IO. ACE 
16 a n IO. DAC 
17 a a IO. RVB 
18 a a IO.WVB 
19 a IO. EXT 
20 a I0.CRE 
21 a IO.DEL 
22 a I0. RAT 
23 a IO.WAT 
24 a I0. APC 
25 
26 
| 27 | 
28 
29 
30 
31 


| t - transfer function, bit set only in legal function 
mask 

| ¢ = control function, bit set in legal and control 

| function masks 

n - no-op function, bit set in legal and no-op 

| function masks 

; a —- ACP function, bit set in legal and ACP function 

| masks 

|sa - special case, bit set only in ACP function mask, | 
but not legal 

sd - special case, bit set only if diagnostic support 
in system and driver 
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4.1.3 The Status Control Block (SCB) 


Figure 4-4 is a layout of the SCB. The SCB describes the status of a 
control unit that can run in parallel with all other control units. 


S.RCNT! J "Offset to Ist me ‘Number of | registers | 
S.ROFF' oe device register Hr to copy on error 

1 1 Saved I/O active bit map \ 
S.BMSV i pointer to Error Message Block | 
S.BMSK' | Device I/O active bit mask 


S.LHD | D | 0 


evice 1/O queue 
listhead 2 


S.PRI | 
, as . . . 4 
S.vcT f Vector address+4 Device priority 


Time-out count: 
Initial Current 


Controller status 10 
) 
1 


2) 
QO 
©) 
2 


S.MPR | 

I--- Storage required for ---! 
I NPR UNIBUS devices 

aks with 22-bit addressing ---- 
] 


1. These offsets exist for mass storage devices only, and only in systems 
incorporating error logging. 
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4.1.3.1 SCB Details - The fields in the SCB are described below: 
S.RCNT (used for error logging) 
Driver Access: 
Not initialized, not referenced. 
Description: 
The number of registers to copy on error. This offset exists 
for mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging. 
S.ROFF (used for error logging) 
Driver Access: 
Not initialized, not referenced. 
Description: 
Offet to first device register. This offset exists for mass 
Storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 
S.BMSV (used for error logging) 
Driver access: 
Not initialized, not referenced. 
Description: 
Saved I/O active bit map and pointer to Error Message Block. 


This offset exists for mass storage devices only (that is, 
when DV.MSD is set), and only in systems incorporating error 


logging. 
S.BMSK (used for error logging) 
Driver access: 
Not initialized, not referenced. 
Description: 
Device I/O active bit mask. This offset exists for mass 
storage devices only (that is, when DV.MSD is set), and only 
in systems incorporating error logging. 
S.LHD (first word equals zero; Second word points to first)+ 


Driver access: 


Initialized, not referenced. 


1. Parenthesized contents indicate values to be initialized in the 
data base source code. 
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Description: 


Two words forming the I/O queue listhead. The first word 
points to the first I/O packet in the queue, and the second 
word points to the last I/O packet in the queue. If the 
queue is empty, the first word is zero, and the second word 
points to the first word. 


S.PRI (device priority) 
Driver access: 
Initialized, read-only. 
Description: 


Contains the priority at which the device interrupts. Use 
symbolic values (for example, PR4) to initialize this field 
in your data base source. You define these symbolic values 
by issuing the HWDDFS macro (refer to the sample data base in 
Section 6.2.1 and the listing of the HWDDFS macro in Appendix 
C). 


S.VCT (interrupt vector divided by 4) 
Driver access: 
Initialized, not referenced. 
Description: 


Interrupt vector address divided by 4. For loadable drivers, 
the MCR/VMR LOA function uses this field and the existence of 
driver symbol(s) S$xxINT, $xxINP, and $xxOUT to initialize the 
device interrupt vector. 


S.CTM (initialize to zero) 
Driver access: 
Not initialized, read-write. 
Description: 


RSX-11M supports device time-out, which enables a driver to 
limit the time that elapses between the issuing of an I/0 
operation and its termination. The current time-out count 
(in seconds) is initialized by moving S.ITM (initial time-out 
count) into S.CTM. The Executive clock service (in module 
TDSCH) examines active times, decrements them, and, if they 
reach zero, calls the driver at its device time-out entry 
point. 


The internal clock count is kept in 1-second increments. 
Thus, a time count of 1 is not precise because the internal 
clocking mechanism is operating asynchronously with driver 
execution. The minimum meaningful clock interval is 2 if you 
intend to treat time-out aS a consistently detectable error 
condition. Note, if the count is 0, that no time-out occurs; 
a zero value is, in fact, an indication that time-out is not 
operative. The maximum count is 255. You are responsible 
for setting this field. Resetting occurs at actual time-out 
or within SFORK. 
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S.ITM (set to initial time-out count) 
Driver access: 
Initialized, read-only. 
Description: 
Contains the initial time-out value. 
S.CON (controller number times 2) 
Driver access: 
Initialized, read-only. 
Description: 


Controller number multiplied by 2. Drivers that are written 
to support more than one controller use this field. A driver 
May use S.CON to index into a controller table created and 
Maintained internally by the driver itself. By indexing the 
controller table, the driver can_ service the correct 
controller when a device interrupts. See Section 4.2 for an 
example. 


S.STS (initialize to zero) 
Driver access: 
Initialized, not referenced. 
Description: 


Establishes the controller as busy/not busy (nonzero/zero). 
This byte is the interlock mechanism for marking a driver as 
busy for a specific controller. The byte is tested and set 
by SGTPKT and reset by SIODON. 


S.CSR (Control Status Register address) 
Driver access: 
Initialized, read-only. 
Description: 


Contains the address of the Control Status Register (CSR) for 
the device controller. The driver uses S.CSR to initiate I/0 
operations and to access, by indexing, other registers 
related to the device that are located in the I/O page. This 
address need not be a CSR; it need only be a member of the 
device's register set. It is accessed at system bootstrap 
time to determine if the interface exists on the system 
hosting the Executive. The Executive uses S.CSR to set the 
off-line bit at bootstrap so that system software can be 
interchanged between systems without an intervening system 
generation. The MCR LOA function also references S.CSR when 
it processes a loadable data base. Otherwise, only the 
driver itself accesses S.CSR. 
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S.PKT (reserve one word of storage) 
Driver access: 
Not initialized, read-only. 
Description: 


Address of the current I/O packet established by S$GTPKT. The 
Executive uses this field to retrieve the I/O packet address 
upon the completion of an I/O request. S.PKT is not zeroed 
after the packet is completed. 


S.FRK (reserve four or five words of storage) 
Driver access: 
Not initialized, not referenced. 
Description: 


The four words starting at S.FRK are used for fork block 
Storage if and when the driver deems it necessary to 
establish itself as a fork process. Fork block storage 
preserves the state of the driver, which is restored when the 
driver regains control at fork level. This area is 
automatically used if the driver calls $FORK. 


The fork block is five words long instead of four if two 
conditions are met: 


1. Loadable drivers have been selected as a SYSGEN 
option. 


2. The system is mapped. 


If these conditions are met, and the fork block is five words 
long, you must not use the fork block for any other purpose. 
In other words, you cannot share the space reserved for the 
fork block; if you attempt to do so, you will destroy the 
loadable driver's relocation base. In addition, the 5-word 
fork block should always be part of the SCB if the two 
conditions above are met. 


S.MPR (reserve Six words of storage) 
Driver access: 
Initialized, read-only. 
Description: 
Drivers use the six words starting at S.MPR for non-processor 
request (NPR) devices attached to a processor with 22-bit 


addressing. See Appendix B for details on initializing 
S.MPR. 


4.1.4 The Unit Control Block (UCB) 


Figure 4-5 is a layout of the UCB (a variable-length control block). 
One UCR exists for each nhvysical device-unit generated into a system 
configuration. For user-added drivers, this control block is defined 
aS part of the source code for the driver data structure. 
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4.1.4.1 UCB Details - The fields in the UCB are described below. 
Note that the fields drawn with dotted outlines are not present in 
every UCB; their existence depends on physical device type, whether 
the system is generated with error logging, and whether you are 
running on a multiuser system. Refer to the individual descriptions 
of the offsets for details. 
U.IOC 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is. set), 
and only in systems incorporating error logging: the total 
number of QIOs issued to the device. (Initialized to zero 
when device is mounted.) 
U.ERSL 
Device access: 
Not initialized, not referenced. 


Description: 


For mass storage devices only (that is, when DV.MSD is set), 
and only in systems incorporating error logging: the maximum 
number of soft errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U.ERHL or in U.ERSL) is exceeded. 


U. ERHL 
Driver access: 
Not initialized, not referenced. 
Description: 
For maSs storage devices only (that is, when DV.MSD is. set), 
and only in systems incorporating error logging: the maximum 
number of hard errors that the error logger will log for the 
device. Note that error logging will stop if either of the 
limits specified (in U.ERHL or in U.ERSL) is exceeded. 
U. ERSC 
Driver access: 
Not initialized, not referenced. 
Description: 
For mass storage devices only (that is, when DV.MSD is’ set), 
and only in systems incorporating error logging: the total 


number of soft errors logged on the device. ({Initialized to 
zero when device is mounted.) 
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U.ERHC 
Driver access: 


Not initialized, not referenced. 


Description: 
For mass storage devices only (that is, when DV.MSD is’ set), 
and only in systems incorporating error logging: the total 


number of hard errors logged on the device. (Initialized to 
zero when device is mounted.) 


NOTE 


The following two symbolic names, U.MUP 
and U.CLI, both refer to the same 
absolute offset; use of the offset is 
dependent on system software 
configuration. Details regarding the 
use of each symbolic name are contained 
in the descriptions of U.MUP and U.CLI. 
U.MUP 
Driver access: 


Not initialized, not referenced. 


Description: 
For terminal UCBs only, and only in multiuser systems’ that 
include alternate CLI support: bits 1 to 4 contain an index 
to a table which contains the address of CLI Parser Block 
(CPB) for the current CLI; the remaining bits are used for 
other terminal-specific features, and defined as follows: 
UM.OVR Override CLI indicator 
UM.CLI CLI indicator 


UM.DSB Terminal disabled because CLI eliminated 
UM.NBR No broadcast 


U.CLI 
Driver access: 
Not initialized, not referenced. 
Description: 
For systems without alternate CLI support, but which do 
include multiuser protection: multiuser protection flag 
word. 
U.LUIC 
Driver access: 
Not initialized, not referenced. 
Description: 


For terminal UCBs only, and only in multiuser systems: the 
login UIC of the user at the particular terminal. 
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[ps 8 et ee ee Se 7T 
— — — — 1/Ocount ----4 
u.1ioc4 
bo ----7----- 
ot) Hard error limit a: Soft error limit 
ul ERScé SS SS Se SS See note 5 
: Hard error count Soft error count 
venw} ees iy ee te i ee | 
U.MUP? Multiuser flags and CLI pointer 1 
U.LUIC? 
U.OWN' Owning terminal UCB address 


U.DCB ; Back pointer to DCB 

U.RED Redirect UCB pointer 

ms =e 
oa 
U.CW1 Characteristics word 1 


U.CW2 Characteristics word 2 
U.CW3 Characteristics word 3 


U.CW4 Characteristics word 4 16 All 


devices 
U.SCB Pointer to SCB 20 


U.ATT | TCB address of attached task 22 


U.BUF Buffer relocation bias 24 
U.BUF+2 Buffer address 26 


Device- 
dependent 


| storage | 


. This offset appears only in multiuser systems. 


. These offsets appear only for terminal devices (that is, those devices that have DV.TTY 
set) in multiuser systems. 


. This offset appears only for terminal devices in multiuser systems that include alternate 
CLI support. In multiuser systems without alternate CL! support, this offset has a symbolic 
name of U.CLI. See descriptions and note in text. 


. These offsets appear only for mass storage devices (those devices that have DV.MSD set) 
in systems that employ error-logging. 


. These offsets are device-dependent. 
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U.OWN (initialize to zero) 
Driver access: 
Initialized, not referenced. 
Description: 


In multiuser systems only: the UCB address of the owning 
terminal for allocated devices. 


U.DCB (pointer to associated DCB) 
Driver access: 
Initialized, not referenced. 
Description: 
Backpointer to the corresponding DCB. Because the UCB is a 
key control block in the I/O data structure, access to other 
control blocks usually occurs by means of links implanted in 
the UCB. 
U.RED (redirect pointer--initialized to point to U.DCB of the UCB) 
Driver access: 
Initialized, not referenced. 
Description: 
Contains a pointer to the UCB to which this device-unit has 
been redirected. This field is updated as the result of an 
MCR Redirect command. The redirect chain ends when this word 
points to the beginning of the UCB itself (U.DCB of the UCB 
to be precise). 
U.CTL (set by you) 
Driver access: 
Initialized, not referenced. 
Description: 
U.CTL and the function mask words in the DCB drive QIO 
directive processing. You are responsible for setting up 
this bit pattern. Any inaccuracy in the bit setting of U.CTL 
produces erroneous I/0 processing. Bit symbols and their 
meanings are as follows: 
UC.ALG - Alignment bit. 
If this bit equals 0, then byte alignment of data buffers 
is allowed. If UC.ALG equals 1, then buffers must be 
aligned on word boundaries. 
UC. ATT - Attach/Detach notification. 
If this bit is set, then the driver is called when SGTPRKT 
processes an Attach/Detach I/O function. Typically, the 
driver does not need to obtain control for Attach/Detach 


requests, and the Executive performs the entire function 
without any assistance from the driver. 
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UC. KIL - Unconditional Cancel I/0 call bit. 


If set, the driver is called on a Cancel I/O request, 
even if the unit specified is not busy. Typically, the 
driver is called on Cancel I/O only if an I/0 operation 
is in progress. 


UC.QUE - Queue bypass bit. 


If set, the QIO directive processor calls the driver 
prior to queuing the I/O packet. After the processor 
makes this call, the driver is responsible for the 
disposition of the I/O packet. Typically, the processor 
queues an I/O packet prior to calling the driver, which 
later retrieves it by a call to $GTPKT. 


UC.PWF - Unconditional call on power failure bit. 


If set and the unit is on line, the driver is always’ to 
be called when the system is bootstrapped or power is 
restored after a power failure occurs. Typically, the 
driver is called on power restoration only when an I/0 
operation is in progress. Additionally, for loadable 
drivers, the driver is called when loaded if the unit is 
on line and UC.PWF is set. 


UC.NPR - NPR device bit. 


If set, the device is an NPR device. This bit determines 
the format of the 2-word address in U.BUF (details given 
in the discussion of U.BUF below). 


UC.LGH - Buffer size mask bits (2 bits). 


These two bits are used to check whether the byte count 
specified in an I/O request is a legal buffer modulus. 
You select one of the values below by ORing into the byte 
a 0, 1, or 3. 


00 - Any buffer modulus valid 
O01 - Must have word alignment modulus 
10 - Combination invalid 


11 - Must have doubleword alignment modulus 

UC.ALG and UC.LGH are independent settings. 
UC.ATT, UC.KIL, UC.QUE, and UC.PWF are usually zero, 
especially for conventional drivers. Every driver, however, 
must be concerned with its particular values for UC.ALG, 
UC.NPR, and UC.LGH. You are totally responsible for the 
values in these bits, and erroneous values are likely to 
produce unpredictable results. 

U.STS (initialize to zero) 
Driver access: 


Initialized, not referenced. 
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Description: 


This byte contains 
The bit meanings are 


device-independent 
as follows: 


Status information. 


US.BSY - If set, device-unit is busy. 
US.MNT - If set, volume is not mounted. 
US.FOR - If set, volume is foreign. 
US.MDM - If set, device is marked for dismount. 
The unused bits in U.STS are reserved for system use _ and 
expansion. US.MDM, US.MNT, and US.FOR apply only to 
mountable devices. 
U.UNIT (unit number) 
Driver access: 
Initialized, read-only. 
Description: 
This byte contains the physical unit number Of the 


device-unit 
access the specified drive unit) 


(that is, the value required for the hardware to 


If the controller for the 


device supports only a single unit, the unit number is always 


ZeLO. 
U.ST2 (set by you) 
Driver access: 


Initialized, not referenced. 


Description: 


This byte contains additional 
information. 
US.OFL - If set, the device 
the configuration). 
US.RED - If set, the device 
US.PUB - If set, the device 
US.UMD - If set, the device 


The remaining bits are reserved 
U.CWl (set by you) 
Driver access: 


Initialized, not referenced. 


device-independent status 


The bit meanings are as follows: 


is off line (that is, not in 


cannot be redirected. 
is a public device. 
is attached for diagnostics. 


for system use and expansion. 
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Description: 


The first of a 4-word contiguous cluster of device 
characteristics information. U.CWl and U.CW4 are device 
independent. U.CW2 and U.CW3 are device dependent. The four 
characteristics words are retrieved from the UCB and placed 
in the requester's buffer on issuance of a Get LUN 
information (GLUNS) Executive directive. It is your 
responsibility to supply the contents of these four words in 
the assembly source code of the driver's data structure. 


U.CWl is defined as follows (If a bit is set to 1, the 
corresponding characteristic is true for the device.): 


DV.REC Bit 0--Record-oriented device 

DV.CCL Bit 1--Carriage-control device 

DV.TTY Bit 2--Terminal device 

DV.DIR Bit 3--Directory device 

DV.SDI Bit 4--Single directory device 

DV.SQOD Bit 5--Sequential device 

DV.MSD Bit 6--Mass storage device 

DV.UMD Bit 7--Device supports user-mode diagnostics 

DV.EXT Bit 8--Device attached to a 22-bit direct addressing 
controller 

DV.SWL Bit 9--Unit is software write-locked 

DV.ISP Bit 10--Input spooled device 

DV.OSP Bit 11--Output spooled device 

DV.PSE Bit 12--Pseudo device 

DV.COM Bit 13--Device mountable as a communications channel 

DV.F1l Bit 14--Device mountable as a Files-11l device 

DV.MNT Bit 15--Device mountable 


U.CW2 (initialize to zero) 
Driver access: 
Initialized, read-write. 
Description: 


Specific to a given device driver (available for working 
storage or constants) .l 


U.CW3 (initialize to zero) 
Driver access: 
Initialized, read-write. 
Description: 


Specific to a given device driver (available for working 
storage or constants) .l 


l. Exception: for block-structured devices, U.CW2 and U.CW3 cannot be 
used for working’ storage. In drivers for block-structured devices 
(disks and DECtape), these two words must be initialized to a 
double-precision number giving the total number of blocks on the 
device. Place the high-order bits in the low-order byte of U.CW2 and 
the low-order bits in U.CW3. 
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For tape UCBs, the high and low bytes of this word specify 
the highest and lowest densities, respectively, supported by 
the device. Symbolic names for U.CW3 are defined as follows 
for tape UCBs: 
UN.UNS Unsupported/unspecified 
UD.200 200 bits/in, 7-track 
UD.556 556 bits/in, 7-track 
UD.800 800 bits/in, 7- or 9-track 
UD.160 1600 bits/in, 9-track 
UD.625 6250 bits/in, 9-track 
For example, a TE16 tape drive supports densities of both 800 
and 1600 bits/in. For a TE16 drive, U.CW3 would be coded as 
follows: 
BYTE UD. 800, UD. 160 
U.Cw4 (set by you) 
Driver access: 
Initialized, read-only. 
Description: 


Default buffer size. This word is changed by the MCR command 
SET /BUF. 


U.SCB (SCB pointer) 
Driver access: 
Initialized, read-only. 
Description: 
This field contains a pointer to the SCB for this UCB. In 
general, R4 contains the value in this word when the driver 
is entered by way of the driver dispatch table, because 
service routines frequently reference the SCB. 
U.ATT (initialize to zero) 
Driver access: 
Initialized, not referenced. 


Description: 


If a task has attached itself to the device-unit, this field 
contains its TCB address. 


U.BUF (reserve two words of storage) 
Driver access: 
Not initialized, read-write. 
Description: 


U.BUF labels two consecutive words’ that serve as a 


communication region between S$GTPKT and the driver. U.BUF, 
U.BUF+2, and U.CNT receive the first three words from the I/0 
packet. 
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For transfer operations, the format of these two words 
depends on the setting of UC.NPR in U.CTL. The driver does 
not format the words; all formatting is completed before the 
driver receives control. For unmapped systems, the first 
word is zero, and the second word is the physical address of 
the buffer. For mapped systems, the format is determined by 
the UC.NPR bit, which is set for an NPR device and reset for 
a program transfer device. 


The format for program transfer devices is identical to that 
for the second two words of I.IOSB in the I/O packet. See 
Section: 4,1, 1.1, 


In general, the driver does not manipulate these words’ when 
performing I/O to a = program transfer device. Instead, it 
uses the Executive routines Get Byte, Get Word, Put Byte, and 
Put Word to effect data transfers between the device and the 
user's buffer. 


For NPR device drivers, the word layout is as follows: 


Word 1 

Bit 0 Go bit initially set to zero 

Bits 1-3 Function code--Sset to zeros 

Bits 4,5 Memory extension bits 

Bits 6 Interrupt enable--set to zero 

Bits 7-15 Zero 

Word 2 

Bits 0-15 Low-order 16-bits of physical address 


It is your responsibility to set the function code, interrupt 
enable, and go bits. This action must be accomplished by a 
Bit Set (BIS) instruction so that the extension bits are not 
disturbed. The driver must move these words into the device 
control registers to initiate the I/O operation. 


Note that when the system is unmapped, bits 4 and 5 are 
always zero, but this fact is transparent to the driver. 
Thus, NPR device drivers are not cognizant of the mapping 
State in the system. 


The construction of U.BUF, U.BUF+2, and U.CNT occurs only if 
the requested function is a transfer function; if it is not, 
these three words contain the first three words of the I/0 
packet. 


The details of the construction of the address doubleword 
appear in Appendix A. 


U.CNT (reserve 1 word of storage) 
Driver access: 
Not initialized, read-write. 
Description: 
Contains the byte count of the buffer described by U.BUF. 


The driver uses this field in constructing the actual device 
request. 
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U.BUF and U.CNT keep track of the current data item in the 
buffer for the current transfer (except for NPR transfers). 
Because this field is being altered dynamically, the I/0 
packet may be needed to reissue an I/O operation, for 
instance, after a powerfail or error retry. 


Device-Dependent Words: 
Driver access: 
Not initialized, read-write. 
Description: 


ou establish this variable-length block of words to suit 
e 


Vv 
a ua 
device-specific requirements. 


4.1.5 The Device Interrupt Vector 


For resident drivers only, the device interrupt vector must be 
initialized when defining data structures, and must not be altered 
dynamically. This practice makes the driver code independent of 
device register address assignments and of the actual location of the 
interrupt vector. The driver data structure must include a_ storage 
assignment and initialization for the interrupt vector with the 
priority set to PR7. See lines 81 through 85 in Section 6.2.1 
(Section 6.2.1 contains the source code for the data structure of a 
sample resident driver). 


Writers of loadable drivers do not initialize the device interrupt 
vector. The vector is dynamically established by the MCR LOA command 
when the driver is loaded. When a driver is unloaded, the MCR UNL 
command sets the vector to the system nonsense interrupt entry point. 


4.2 MULTICONTROLLER DRIVERS 


This section discusses the conditional code needed at the interrupt 
entry point of a driver that may handle one or several device 
controllers. This discussion leads to a description in the next 
section of the system macro INTSV$. INTSVS contains multicontroller 
conditionals and other features to simplify interrupt entry coding. 


Figure 4-6 shows the interrupt entry coding from the paper-tape-punch 
driver. This is an earlier version of the driver presented in its 
entirety in Section 6.2.2. 


The coding is conditionalized on PS$P1l1-1l. The symbol PSSP11 
represents the number of controllers and is set at SYSGEN. 


In a multicontroller device configuration, the controllers are 
numbered starting with 0. The code for a multicontroller driver 
contains a table (called CNTBL in the example in Figure 4-6) whose 
length in words is equal to the number of controllers. A number 
called the controller index--equal to the controller number’ times 
2--is stored in the SCB for each controller, in byte S.CON. 


When an I/O request occurs, and the driver is called at its initiator 
entry point, the driver first calls SGTPKT to obtain an I/0 packet to 
Process. Among the values returned by SGTPKT are the controller index 
(obtained from S.CON in the SCB) and the address of the UCB for the 
unit requesting I/O service. 
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The driver stores the requesting unit's UCB address in the controller 
table (CNTB1) at an offset equal to the controller index. Thus, for 
the driver at its interrupt entry point to access the requesting UCB, 
it needs simply to obtain the controller index. 


The controller index is obtained from the controller number, which is 
encoded in the lowest four bits of the PS word in the device's 
interrupt vector. At its interrupt entry point the driver first saves 
the PS (line 9. in Figure 4-6), which was set from the device's 
interrupt vector upon interrupt. The PS must be saved with the first 
instruction of interrupt code because its lower four bits are the 
processor condition code bits, which generally change after each 
instruction is issued. Later, after the call to SINTSV, the driver 
constructs the controller index from the saved PS (lines 17.-19.). It 
then uses this index to obtain the UCB address (line 20.). 


For single-controller devices, CNTBL is one word, TEMP is not needed 
to store the PS, and the UCB address is always the first (and only) 
entry in CNTBL. 


NOTE 


The code sequence used in the following 
example is not valid for a loadable 
driver. 


a es 

2 ; **-SPPINT-PC1ll PAPER TAPE PUNCH CONTROLLER INTERRUPTS 

3 ;- 

4 

5 SPPINT:: 737 REF LABEL 

6 

7 -IF GT PSSP1l1-1 

8 

9 MOV PS, TEMP 737 ;SAVE CONTROLLER NUMBER 

10 

11 . [FTF 

12 

13 CALL SINTSV, PR4 3;;SAVE REGISTERS AND SET PRIORITY 
14 

15 . IFT 

16 

17 MOV TEMP, R4 7; ;RETRIEVE CONTROLLER NUMBER 
18 BIC #177760,R4 33;CLEAR ALL BUT CONTROLLER NUMBER 
19 ASL R4 33;CONVERT TO CONTROLLER INDEX 
20 MOV CNTBL(R4),R5 33; RETRIEVE ADDRESS OF UCB 

21 

22 eIFF 

23 

24 MOV CNTBL,R5 +;;RETRIEVE ADDRESS OF UCB 

25 

26 « ENDC 


Figure 4-6 Conditional Code for a Multicontroller Driver 
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4.3 THE INTSVS MACRO 


INTSVS is a system macro that minimizes coding differences between 
loadable and resident drivers. INTSVS contains conditionaily 
assembled code to handle: 


e Single or multiple controllers 

e Loadable or resident drivers 

e Mapped or unmapped systems 
You can replace all the code in Figure 4-6 between lines 7 and 26 with 
the INTSVS macro (as is done in the sample driver illustrated in 
Section 6.2.2). This is required for loadabie drivers on mapped 
systems, because interrupts from hardware devices must be processed in 
kernel address space. In particular, the decoding of the PS word and 
the call to SINTSV must be done before entering the driver. Thus, a 
call to the Executive routine SINTSV within a loadabie driver is 
illegal, and the MCR LOA function returns an error if loading is 
attempted. 
When the INTSVS macro is used for a loadable driver in a mapped 
system, the code from lines 9 to 19 inclusive (Figure 4-6) is not 
assembled as part of the driver. Instead, the LOA function allocates 
a block of dynamic memory in kernel address space to contain the 
interrupt coding. This block, called the Interrupt Control Block 
(ICB), also contains coding to perform the following: 

1. Save the kernel mapping (APR5) 

2. Load APR5 to map the driver 

3. Transfer to the driver 

4. Restore the mapping after return 


The LOA function also sets up the controller's interrupt vector. so 
that hardware interrupts point to the ICB. 


Finally, using the INTSV$ macro in a loadable driver on a ée mapped 
system requires that the symbol LDS$xx (where xx is the 2-character 


device mnemonic) be defined either in the driver source or the 
assembly prefix file RSXMC.MAC. 


4.3.1 Format 
The format of the INTSV$ macro is: 
INTSVS xx,pri,nctlr[,pssave,ucbsave] 
XX 
The 2-character device mnemonic. 
pri 


The priority of the device (the priority that would be used in a 
call to SINTSV). 
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ncetlr 


The number of controllers the driver services. 


pssave 


An optional argument specifying a variable in which to save _ the 
PS word. If omitted, a variable named TEMP is used. 


ucbsave 


An optional argument specifying a block of contiguous words in 
Which to retrieve the interrupting device's UCB address. If 
omitted, a block of contiguous words named CNTBL is used. 


Outputs: R4 is the controller index, only if nctlr is greater than 
l. 


R5 is the UCB address. 
Example: 
INTSVS PP,PR4,PS$P11 
This usage of INTSV$ would effectively replace lines 7 through 26 in 


Figure 4-6. (PSSP11 is a symbol equated to the number of 
controllers.) 


CHAPTER 5 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


This section contains the Executive routines typically used by I/0 
drivers. They are listed in alphabetical order. The descriptions are 
taken directly from the source code for the associated services. 


We describe only the most widely used subroutines. Many other 
Executive service subroutines are available in modules IOSUB.MAC, 
EXESB.MAC, MEMAP.MAC, SYSXT.MAC, QUEUE.MAC, CORAL.MAC, and REQSB.MAC 
in. UPD [l1l, 10) 


5.1 SYSTEM STATE REGISTER CONVENTIONS 


In system state, R5 and R4 are, by convention, nonvolatile registers. 
This means that an internally called routine is required to save and 
restore these two registers if the routine destroys their contents. 
R3, R2, Rl, and RO are volatile registers and may be used by a called 
routine without save and restore responsibilities. 


When a driver is entered directly from an interrupt, it is operating 
at interrupt level, not at system state. At interrupt level, any 
register the driver uses must be saved and restored. INTSVS preserves 
R5 and R4 for the driver's use. 


A routine may violate these conventions as long as an explicit 
statement exists in the program preface detailing the departure from 
conventions. Such departures should generally be avoided; they 
should be employed only when you can demonstrate that a departure from 
convention can improve overall system performance. 


See D.DSP in Section 4.1.2.1 for the contents of registers when a 
driver is entered. 


5.2 CONDITIONAL ROUTINES 


Two of the routines (S$GTWRD and S$PTWRD) discussed in this chapter 
normally are assembled conditionally out of the Executive code. If a 
user-written driver requires either of these routines, the appropriate 
question must be answered affirmatively in the system generation 
dialog. See the descriptions of S$GTWRD and S$PTWRD below. 


5.3 SERVICE CALLS 


In the following descriptions, the file names mentioned are _ source 
modules found on the Executive source disk as [11,10]filnam.MAC. 
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S$ACHKB/SACHCK 


ADDRESS CHECK 
These routines are in the file EXESB. A driver may call either 
routine to address-check a task buffer while the task is the current 
task. The SACHKB and SACHCK routines are normally used only by 
drivers setting UC.QUE in U.CTL. See Section 6.3 for an example. 
Calling sequences: 
CALL SACHKB 
or 


CALL SACHCK 


Description: 


+ 


**-SACHKB-ADDRESS CHECK BYTE ALIGNED 
**k-SACHCK-ADDRESS CHECK WORD ALIGNED 


THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE 
WHETHER IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK. 


INPUTS: 


RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED. 
R1=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES. 


OUTPUTS: 


C=1 IF ADDRESS CHECK FAILED. 
C=0 IF ADDRESS CHECK SUCCEEDED. 


RO AND R3 ARE PRESERVED ACROSS CALL. 
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$ALOCB 


ALLOCATE CORE BUFFER 
This routine is in the file CORAL. 
Calling sequences: 
CALL SALOCB 
or 


CALL SALOC1 


+ 


**-SALOCB-ALLOCATE CORE BUFFER 
**-~SALOC1-ALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO ALLOCATE AN EXEC CORE BUFFER. THE 
ALLOCATION ALGORITHM IS FIRST FIT AND BLOCKS ARE ALLOCATED IN 
MULTIPLES OF FOUR BYTES. 

INPUTS: 


RO=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT SALOC1. 
R1=SIZE OF THE CORE BUFFER TO ALLOCATE IN BYTES. 


OUTPUTS: 


Cc 
Cc 


1 IF INSUFFICIENT CORE IS AVAILABLE TO ALLOCATE THE BLOCK. 
0 IF THE BLOCK IS ALLOCATED. 

RO=ADDRESS OF THE ALLOCATED BLOCK. 

R1=LENGTH OF BLOCK ALLOCATED. 
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SASUMR 


ASSIGN UNIBUS MAPPING REGISTERS 


This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/O driver. 
Rather, it is called from within the SSTMAP routine. Refer to 
Appendix B for a discussion. 


Calling sequence: 


CALL SASUMR 


Description: 
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+ 


**-SSASUMR-ASSIGN UNIBUS MAPPING REGISTERS 


THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR'S. NOTE THAT 
FOR THE SAKE OF SPEED, THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK 
POINTS TO THE UMR ADDRESS (2ND) WORD OF THE BLOCK, NOT THE FIRST WORD. 
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF 
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE 
FIRST UMR ASSIGNED AND THE NUMBER OF UMR'S ASSIGNED TIMES 4. THE 
BLOCKS ARE LINKED IN THE ORDER OF INCREASING FIRST UMR ADDRESS. 


INPUTS: 


RO=POINTER TO A MAPPING REGISTER ASSIGNMENT BLOCK. 
M.UMRN(RO)=NUMBER OF UMR'S REQUIRED * 4. 


OUTPUTS: 
ALL REGISTERS ARE PRESERVED. 


C=0 IF THE UMR'S WERE SUCCESSFULLY ASSIGNED. 
ALL FIELDS OF THE MAPPING REGISTER ASSIGNMENT BLOCK 
ARE INITIALIZED AND THE BLOCK IS LINKED INTO 
THE ASSIGNMENT LIST. 
C=1 IF THE UMR'S COULD NOT BE ASSIGNED. 
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$SCLINS 


CLOCK QUEUE INSERTION 
This routine is in the file QUEUE. 
Calling sequenee: 

CALL SCLINS 


Description: 


+ 


**-SCLINS-CLOCK QUEUE INSERTION 


THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. THE ENTRY 
IS INSERTED SUCH THAT THE CLOCK QUEUE IS ORDERED IN ASCENDING TIME, 
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST. 


INPUTS: 


RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK. 
R1=HIGH ORDER HALF OF DELTA TIME. 

R2=LOW ORDER HALF OF DELTA TIME. 

R4=REQUEST TYPE. 

R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER. 


OUTPUTS: 


THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING 
TO THE TIME THAT IT WILL COME DUE. 


™e 6 ™e Ne MO Ne we NOH Re WH We We We We WOH We Me WH NH We 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$DEACB 


DEALLOCATE CORE BUFFER 
This routine is in the file CORAL. 
Calling sequences: 
CALL S$DEACB 
or 


CALL $DEAC1 


+ 


**—SDEACB-DEALLOCATE CORE BUFFER 
**-SDEAC1-DEALLOCATE CORE BUFFER (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED TO DEALLOCATE AN EXEC CORE BUFFER. THE BLOCK 
IS INSERTED INTO THE FREE. BLOCK CHAIN BY CORE ADDRESS. IF AN 
ADJACENT BLOCK IS CURRENTLY FREE, THEN THE TWO BLOCKS ARE MERGED 
AND INSERTED IN THE FREE BLOCK CHAIN. 


INPUTS: 


RO=ADDRESS OF THE CORE BUFFER TO BE DEALLOCATED. 
R1=SIZE OF THE CORE BUFFER TO DEALLOCATE IN BYTES. 
R3=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT SDEACI. 


OUTPUTS: 


THE CORE BLOCK IS MERGED INTO THE FREE CORE CHAIN BY CORE 
ADDRESS AND IS MERGED IF NECESSARY WITH ADJACENT BLOCKS. 
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$DEUMR 


DEASSIGN UNIBUS MAPPING REGISTERS 
This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. Normally, it is not called directly by an I/O driver. 
Rather, it is called from within the SIODON routine. Refer to 
Appendix B for a discussion. 
Calling sequence: 

CALL SDEUMR 


Description: 


+ 


**-SDEUMR-DEASSIGN UNIBUS MAPPING REGISTERS 

THIS ROUTINE IS CALLED TO DEASSIGN A CONTIGUOUS BLOCK OF UMR'S. IF 
THE MAPPING ASSIGNMENT BLOCK IS NOT IN THE LIST, NO ACTION IS TAKEN. 
NOTE THAT FOR THE SAKE OF ASSIGNMENT SPEED, THE LINK WORD POINTS TO 
THE UMR ADDRESS (2ND) WORD OF THE ASSIGNMENT BLOCK. 


INPUTS: 
R2=POINTER TO ASSIGNMENT BLOCK. 


OUTPUTS: 


RO AND R1 ARE PRESERVED. 
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$DVMSG 


DEVICE MESSAGE OUTPUT 
This routine is in file EXESB. 
Calling sequence: 

CALL SDVMSG 


Description: 


+ 


**-—~SDVMSG-DEVICE MESSAGE OUTPUT 


THIS ROUTINE IS CALLED TO SUBMIT A MESSAGE TO THE TASK TERMINATION 
NOTIFICATION TASK. MESSAGES ARE EITHER DEVICE RELATED OR A 
CHECKPOINT WRITE FAILURE FROM THE LOADER. 


INPUTS: 


RO=MESSAGE NUMBER, 
R5=ADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO. 


OUTPUTS: 


A FOUR WORD PACKET IS ALLOCATED, RO AND R5 ARE STORED IN THE 
SECOND AND THIRD WORDS, RESPECTIVELY, AND THE PACKET IS 
THREADED INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE 
QUEUE. 


NOTE: IF THE TASK TERMINATION NOTIFICATION TASK IS NOT 
INSTALLED OR NO STORAGE CAN BE OBTAINED, THEN THE 
MESSAGE REQUEST IS IGNORED. 
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Note: 


Drivers use only two codes in calling $DVMSG: T.NDNR (device not 
ready), and T.NDSE (select error). SDVMSG can be set up and 
called as follows: 

MOV _-#T.NDNR,RO 


or 


MOV #T.NDSE, RO 
CALL SDVMSG 


EXECUTIVE 
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$EXRQP 


EXECUTIVE REQUEST WITH QUEUE INSERT BY PRIORITY 


This routine is in the file REQSB. SEXROQP requests the execution of a 
task after inserting a packet into the receive list of the task. 


Calling sequence: 
CALL SEXRQP 


Description: 


+ 


“eo ™e 


**—-SEXROP-EXECUTI VE 
**—SEXRQF-EXECUTI VE 
**—~SEXROQN-EXECUTI VE 
**-—-SEXRQU-EXECUTIVE 
**-SEXRQS—-EXECUTI VE 


THE EXECUTIVE 


INPUTS: 


OUTPUTS: 
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REQUEST WITH QUEUE INSERT BY PRIORITY 
REQUEST WITH QUEUE INSERT FIFO 

REQUEST WITH NO QUEUE INSERTION 

UNSTOP AND REQUEST WITH NO QUEUE INSERTION 
REQUEST WITH NO CONDITIONAL SCHEDULE REQUEST 


THESE ROUTINES PROVIDE A STANDARD INTERFACE TO ALL TASKS REQUESTED BY 


RO=TCB ADDRESS OF TASK TO REQUEST 
R1=ADDR OF PACKET TO QUEUE TO TASK (IF ENTRY AT SEXRQP/SEXROF) 


C=0 IF THE REQUEST WAS SUCCESSFULLY COMPLETED. 
C=l1 IF THE TASK WAS NOT SUCCESSFULLY REQUESTED. 
Z=0 IF PCB ALLOCATION FAILURE. 
Z=l1 IF TASK ACTIVE, BEING REMOVED, OR BEING FIXED. 
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$FORK 


FORK 

This routine is in the file SYSXT. A driver calls S$FORK to switch 
from a partially interruptable level (its state following a call on 
SINTSV) to a fully interruptable level. 

Calling sequence: 


CALL SFORK 


Description: 


+ 


**-SFORK-FORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS CALLED FROM AN I/O DRIVER TO CREATE A SYSTEM PROCESS THAT 
WILL RETURN TO THE DRIVER AT STACK DEPTH ZERO TO FINISH PROCESSING. 


INPUTS: 
R5=ADDRESS OF THE UCB FOR THE UNIT BEING PROCESSED. 
OUTPUTS: 
REGISTERS R5 AND R4 ARE SAVED IN THE CONTROLLER FORK BLOCK AND 


A SYSTEM PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK 
QUEUE AND A JUMP TO SINTXT IS EXECUTED. 
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Notes: 


1. SFORK cannot be called unless SINTSV has been previously 
called. The fork-processing routine assumes that SINTSV has 
set up entry conditions. 


2. A driver's current time-out count is cleared in calls to 
SFORK. This protects the driver from synchronization 
problems that can occur when an I/O request and the time-out 
for that request happen at the same time. After a return 
from a call to $FORK, a driver's time-out code will not be 
entered. 


If the clearing of the time-out count is not deSired, a 
driver has two alternatives: 


a. Perform time-out operations by directly inserting 
elements in the clock queue (refer to the description of 
the SCLINS routine). 


b. Perform necessary initialization, including clearing 
S.STS in the SCB to zero (establishing the controller as 
not busy), and call the $FORK1 routine rather than SFORK. 
Calling SFORK] bypasses the clearing of the current 
time-out count. 


3. The driver must not have any information on the stack when 
SFORK is called. 


FORK1 
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SFORK1 


This routine is in the file SYSXT. A driver calls S$FORK1 to bypass 
the clearing of its time-out count when it switches from a partially 
interruptable level to a fully interruptable level (refer also to the 
description of the SFORK routine). . 


Calling sequence: 


CALL SFORK1 


Description: 


+ 
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Notes: 


INPUTS: 


**-SFORK1-FORK AND CREATE SYSTEM PROCESS 


THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND 
SAVE REGISTER R5. 


R4=ADDRESS OF THE LAST WORD OF A 3 WORD FORK BLOCK PLUS 2. 
R5=REGISTER TO BE SAVED IN THE FORK BLOCK. 


OUTPUTS: 
REGISTER R5 IS SAVED IN THE SPECIFIED FORK BLOCK AND A SYSTEM 


PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK QUEUE 
AND A JUMP TO SINTXT IS EXECUTED. 


For mapped systems with loadable driver support, a 5-word 
fork block is required for calls to S$FORK1. 


When a 5-word fork block is used, the driver must initialize 
the fifth word with the base address (in 32-word blocks) of 
the driver partition. This address can be obtained from the 
fifth word of the standard fork block in the SCB. 


The driver must not have any information on the stack when 
SFORK1 is called. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTBYT 


GET BYTE 


This routine is in the file BFCTL. S$GTBYT manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling sequence: 
CALL SGTBYT 


Description: 


+ 


*k-SGTBYT-GET NEXT BYTE FROM USER BUFFER 

THIS ROUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE BYTE HAS BEEN 
FETCHED, THE NEXT BYTE ADDRESS IS INCREMENTED. 


INPUTS: 
R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
OUTPUTS: 
THE NEXT BYTE IS FETCHED FROM THE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK. THE NEXT BYTE ADDRESS IS 
INCREMENTED. 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTPKT 


GET PACKET 


This routine is in the file IOSUB. 


Calling sequence: 
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CALL SGT PKT 


+ 


**-SGTPKT-GET I/O PACKET FROM REQUEST QUEUE 


THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O 
REQUEST TO PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY 
SET INDICATION IS RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO 
DEQUEUE THE NEXT REQUEST FROM THE CONTROLLER QUEUE. IF NO REQUEST 
CAN BE DEQUEUED, THEN A CARRY SET INDICATION IS RETURNED TO THE 
CALLER. ELSE THE CONTROLLER IS SET BUSY AND A CARRY CLEAR 

INDICATION IS RETURNED TO THE CALLER. 


INPUTS: 
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO GET A PACKET FOR. 
OUTPUTS: 


C=1 IF CONTROLLER IS BUSY OR NO REQUEST CAN BE DEQUEUED. 
C=0 IF A REQUEST WAS SUCCESSFULLY DEQUEUED. 
R1=ADDRESS OF THE I/O PACKET. 
R2=PHYSICAL UNIT NUMBER, 
R3=CONTROLLER INDEX. 
R4=ADDRESS OF THE STATUS CONTROL BLOCK. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 


NOTE: R4 AND R5 ARE DESTROYED BY THIS ROUTINE. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$GTWRD 


GET WORD 


This routine is in the file BFCTL. SGTWRD manipulates words U.BUF and 
U.BUF+2 in the UCB, and is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN when the following question is asked: 

*26. Include routine $GTWRD? [Y/N]: 


If an LPA11 device (LA:) is included in your system, the S$GTWRD 
routine is automatically included and Question 26 is not asked. 


Calling sequence: 
CALL SGTWRD 


Description: 


+ 


**-SGTWRD-GET NEXT WORD FROM USER BUFFER 
THIS ROUTINE IS CALLED TO GET THE NEXT WORD FROM THE USER BUFFER 
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE WORD HAS BEEN 
FETCHED, THE NEXT WORD ADDRESS IS CALCULATED. 
INPUTS: 

R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
OUTPUTS: 


THE NEXT WORD IS FETCHED FROM THE USER BUFFER AND RETURNED 
TO THE CALLER ON THE STACK. THE NEXT WORD ADDRESS IS CALCULATED. 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SINTSV 


INTERRUPT SAVE 


This routine is in the file SYSXT. 


Calling sequence: 


CALL SINTSV, PRn 


n has a range of 0-7. 


Description: 
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+ 


**-SINTSV-INTERRUPT SAVE 


THIS ROUTINE IS CALLED FROM AN INTERRUPT SERVICE ROUTINE WHEN AN 
INTERRUPT IS NOT GOING TO BE IMMEDIATELY DISMISSED. A SWITCH TO 

THE SYSTEM STACK IS EXECUTED IF THE CURRENT STACK DEPTH IS +1. WHEN 
THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS, 
JUMPS TO SINTXT, OR EXECUTES A RETURN. 


INPUTS: 


4(SP)=PS WORD PUSHED BY INTERRUPT. 
2(SP)=PC WORD PUSHED BY INTERRUPT. 
0(SP)=SAVED R5 PUSHED BY 'JSR R5,SINTSV'. 
0(R5)=NEW PROCESSOR PRIORITY. 


OUTPUTS: 


REGISTER R4 IS PUSHED ONTO THE CURRENT STACK AND THE CURRENT 
STACK DEPTH IS DECREMENTED. IF THE RESULT IS ZERO, THEN 

A SWITCH TO THE SYSTEM STACK IS EXECUTED. THE NEW PROCESSOR 
STATUS IS SET AND A CO-ROUTINE CALL TO THE CALLER IS EXECUTED. 


Note: 


A system macro, INTSVS, is provided to simplify the coding of 
Standard interrupt entry processing. See Section 4.3. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SINTXT 


INTERRUPT EXIT 
This routine is in the file SYSXT. 
Calling sequence: 
JMP SINTXT 
or 
RETURN (if a call to SINTSV has been executed) 


Description: 


+ 


**-SINTXT-INTERRUPT EXIT 


THIS ROUTINE IS CALLED VIA A RETURN TO EXIT FROM AN INTERRUPT. IF THE 
STACK DEPTH IS NOT EQUAL TO ZERO, THEN REGISTERS R4 AND R5 ARE 
RESTORED AND AN RTI IS EXECUTED. ELSE A CHECK IS MADE TO SEE 

IF THERE ARE ANY ENTRIES IN THE FORK QUEUE. IF NONE, THEN R4 AND 

R5 ARE RESTORED AND AN RTI IS EXECUTED. ELSE REGISTERS R3 THRU 

RO ARE SAVED ON THE CURRENT STACK AND A DIRECTIVE EXIT IS EXECUTED. 


INPUTS: (MAPPED SYSTEM) 
06(SP)=PS WORD PUSHED BY INTERRUPT. 
04(SP)=PC WORD PUSHED BY INTERRUPT. 
02(SP)=SAVED R5. 
00(SP)=SAVED R4. 

INPUTS: (REAL MEMORY SYSTEM) 


NONE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SIOALT/SIODON 


I/O DONE ALTERNATE ENTRY and I/O DONE 
These routines are in the file IOSUB. 
Calling sequences: 


CALL SIOALT 
CALL SIODON 


Description: 


+ 


**-SIOALT-I/O DONE (ALTERNATE ENTRY) 
**-STODON-I/0O DONE 
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THIS ROUTINE IS CALLED BY DEVICE DRIVERS AT THE COMPLETION OF AN I/O REQUEST 
TO DO FINAL PROCESSING. THE UNIT AND CONTROLLER ARE SET IDLE AND SIOFIN IS 
ENTERED TO FINISH THE PROCESSING. 
INPUTS: 
RO=FIRST I/O STATUS WORD. 
R1=SECOND I/O STATUS WORD. 
R2=STARTING AND FINAL ERROR RETRY COUNTS IF ERROR LOGGING DEVICE. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED. 


NOTE: IF ENTRY IS AT SIOALT, THEN Rl IS CLEARED TO SIGNIFY THAT THE 
SECOND STATUS WORD IS ZERO. 


OUTPUTS: 
THE UNIT AND CONTROLLER ARE SET IDLE. 


R3=ADDRESS OF THE CURRENT I/O PACKET. 


oe me NO Te MO TO TO HO MO TO MS Ne MO Te MO NSH MO MO MO NO 


NOTE 


R4 is destroyed when either of these 
routines is called. The routines call 
SIOFIN, which destroys R4. 


These routines push the address of 
routine S$DQUMR onto the stack before 
returning to the driver. This precludes 
the use of the stack for temporary data 
Storage by drivers when calling these 
routines. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SIOFIN 


I/O FINISH 


This routine is in the file IOSUB. Most drivers do not call SIOFIN, 
but you should be aware that this routine is executed when a driver 
calls $IOALT or S$IODON. A driver that references an I/O packet before 
it is queued (bit UC.QUE set--see Section 6.3 for an example) calls 
SIOFIN if the driver finds an error while preprocessing the I/0 
packet. 


Calling sequence: 
CALL SIOFIN 


Description: 


+ 


**-~STOFIN-I/O FINISH 


THIS ROUTINE IS CALLED TO FINISH I/O PROCESSING IN CASES WHERE THE UNIT AND 
CONTROLLER ARE NOT TO BE DECLARED IDLE. 


INPUTS: 
RO=FIRST I/O STATUS WORD. 
R1=SECOND I/O STATUS WORD. 
R3=ADDRESS OF THE I/O REQUEST PACKET. 
R5=ADDRESS OF THE UNIT CONTROL BLOCK. 
OUTPUTS: 
THE FOLLOWING ACTIONS ARE PERFORMED: 


1-THE FINAL I/O STATUS VALUES ARE STORED IN THE I/0 STATUS BLOCK IF 
ONE WAS SPECIFIED. 


2-THE I/O REQUEST COUNT IS DECREMENTED. IF THE RESULTANT COUNT IS 
ZERO, THEN 'TS.RDN' IS CLEARED IN CASE THE TASK WAS 
STOPPED FOR I/O RUNDOWN. 


3-IF 'TS.CKR' IS SET, THEN IT IS CLEARED AND CHECKPOINTING OF THE 
TASK IS INITIATED. 


4-IF AN AST SERVICE ROUTINE WAS SPECIFIED, THEN AN AST IS QUEUED 
FOR THE TASK. ELSE THE I/O PACKET IS DEALLOCATED. 


5-A SIGNIFICANT EVENT OR EQUIVALENT IS DECLARED. 


NOTE: R4 IS DESTROYED BY THIS ROUTINE. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$MPUBM 


MAP UNIBUS TO MEMORY 

This routine is in the file MEMAP. SMPUBM is used only for NPR 
devices requiring UNIBUS Mapping Registers, when 22-bit memory 
addressing is enabled. See Appendix B for a discussion. 

Calling sequence: 


CALL SMPUBM 


Description: 


+ 


**—-SMPUBM-MAP UNIBUS TO MEMORY 

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEM- 
ORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. 

INPUTS: 


R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB. 


OUTPUTS: 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE TRANSFER 
ARE LOADED. 


NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$MPUB1 


MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 
This routine is in file MEMAP. It is used only for NPR devices’ that 
require UNIBUS Mapping Registers, support parallel operations, and 
have 22-bit memory addressing enabled. See Appendix B for a 
discussion of using this routine. 
Calling sequence: 

CALL SMPUB 1 


Description: 


+ 


**-SMPUB1-MAP UNIBUS TO MEMORY (ALTERNATE ENTRY) 


THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE 
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN 

MEMORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. THIS ALTERNATE 
ENTRY POINT ALLOWS THE DRIVER TO SPECIFY A NON-STANDARD UMR MAPPING 
ASSIGNMENT BLOCK. 


INPUTS: 
RO=ADDRESS OF A UMR MAPPING ASSIGNMENT BLOCK 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 


OUTPUTS: 


THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE 
TRANSFER ARE LOADED 


NOTE: REGISTER R3 IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/0 DRIVERS 


S$PTBYT 


PUT BYTE 


This routine is in the file BFCTL. SPTBYT manipulates words U.BUF and 
U.BUF+2 in the UCB. 


Calling sequence: 
CALL SPTBYT 


Description: 


+ 


**-SPTBYT-PUT NEXT BYTE IN USER BUFFER 

THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN 

USER BUFFER. AFTER THE BYTE HAS BEEN STORED, THE NEXT BYTE ADDRESS 
IS INCREMENTED. 

INPUTS: 


R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER, 


OUTPUTS: 


THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK. THE NEXT BYTE ADDRESS IS INCREMENTED. 
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ALL REGISTERS ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$PTWRD 


PUT WORD 
This routine is in the file BFCTL. S$PTWRD manipulates words U.BUF and 
U.BUF+2 in the UCB. SPTWRD is conditionally assembled. If your 
user-written driver requires this routine, answer Yes during Phase I 
of SYSGEN to the following question: 

*27. Include routine $PTWRD? [Y/N]: 
If an ADO1 A/D controller device (AF:) or an AFC11l A/D controller 
device (AF:) is included in your system, the S$PTWRD routine is 
automatically included and Question 27 is not asked. 

Do you intend to include a user written driver? [Y/N]: 
Calling sequence: 


CALL SPTWRD 


Description: 


+ 


**-SPTWRD-PUT NEXT WORD IN USER BUFFER 

THIS ROUTINE IS CALLED TO PUT A WORD IN THE NEXT LOCATION IN 

USER BUFFER. AFTER THE WORD HAS BEEN STORED, THE NEXT WORD ADDRESS 
IS CALCULATED. 

INPUTS: 


R5=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS. 
2(SP)=WORD TO BE STORED IN THE NEXT LOCATION OF THE BUFFER. 


OUTPUTS: 


THE WORD IS STORED IN THE USER BUFFER AND REMOVED FROM 
THE STACK. THE NEXT WORD ADDRESS IS CALCULATED. 


ALL REGISTERS ARE PRESERVED ACROSS CALL. 


™e me MO Ne Me Ge MO MO MO NO NO BSE MO We We We BMA WH We 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$QINSP 


QUEUE INSERTION BY PRIORITY 
This routine is in the file QUEUE. A driver may call S$QINSP to insert 
into the I/0 queue an I/O packet that the Executive has not already 
Placed in the queue. SQINSP is used only by drivers setting UC.QUE in 
U.CTL. See Section 6.3 for an example. 
Calling sequence: 

CALL SQINSP 


Description: 


+ 


**k-SQINSP-~QUEUE INSERTION BY PRIORITY 
THIS ROUTINE IS CALLED TO INSERT AN ENTRY IN A PRIORITY ORDERED 
LIST. THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A 
LOWER PRIORITY OR THE END OF THE LIST IS REACHED. THE NEW 
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT. 
INPUTS: 

RO=ADDRESS OF THE TWO WORD LISTHEAD. 

R1=ADDRESS OF THE ENTRY TO BE INSERTED. 
OUTPUTS: 

THE ENTRY IS LINKED INTO THE LIST BY PRIORITY. 


RO AND Rl ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


SQRMVF 


QUEUE REMOVAL FROM FRONT OF LIST 
This routine is in the file QUEUE. 
Calling sequence: 

CALL SQRMVF 


Description: 


+ 


**—-SQORMVG-QUEUE REMOVAL FROM FRONT OF LIST 


THIS ROUTINE IS CALLED TO REMOVE THE NEXT (FRONT) ENTRY FROM A 
LIST. THE LIST ORGANIZATION MAY BE EITHER FIFO OR BY PRIORITY. 


INPUTS: 
RO=ADDRESS OF THE TWO WORD LISTHEAD. 
OUTPUTS: 
C=]1 IF THERE ARE NO ENTRIES IN THE LIST. 
C=0 IF THE NEXT ENTRY IS REMOVED FROM THE LIST. 
R1=ADDRESS OF THE ENTRY REMOVED. 


RO IS PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$RELOC 


RELOCATE 
Relocate is in the file MEMAP., A driver may call $RELOC to relocate a 
task virtual address while the task is the current task. Relocate is 
normally used only by drivers setting UC.QUE in U.CTL. See Section 
6.3 for an example. 
Calling Sequence: 

CALL SRELOC 


Description: 


+ 


**~SRELOC-RELOCATE USER VIRTUAL ADDRESS 


THIS ROUTINE IS CALLED TO TRANSFORM A 16 BIT USER VIRTUAL ADDRESS 
INTO A RELOCATION BIAS AND DISPLACEMENT IN BLOCK RELATIVE TO APR6. 


INPUTS: 
RO=USER VIRTUAL ADDRESS TO RELOCATE, 
OUTPUTS: 


R1=RELOCATION BIAS TO BE LOADED INTO PAR6. 
R2=DISPLACEMENT IN BLOCK PLUS 140000 (PAR6 BIAS). 


RO AND R3 ARE PRESERVED ACROSS CALL. 
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EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$STMAP 


SET UP UNIBUS MAPPING ADDRESS 


This routine is in the file MEMAP. It is used only for NPR devices 
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is 
enabled. See Appendix B for a discussion. 


Calling sequence: 


CALL SSTMAP 


Description: 
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+ 


**k-SSTMAP-SET UP UNIBUS MAPPING ADDRESS 


THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO SET UP THE 
UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR'S. IF THE UMR'S 
CANNOT BE ALLOCATED, THE DRIVER'S MAPPING ASSIGNMENT BLOCK IS PLACED 
IN A WAIT QUEUE AND A RETURN TO THE DRIVER'S CALLER IS EXECUTED. THE 
ASSIGNMENT BLOCK WILL EVENTUALLY BE DEQUEUED WHEN THE UMR'S ARE 
AVAILABLE AND THE DRIVER WILL BE REMAPPED AND RETURNED TO WITH R1-R5 
PRESERVED AND THE NORMAL OUTPUTS OF THIS ROUTINE. THE DRIVER'S 
CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHILE IT IS 
BLOCKED AND IN THE WAIT QUEUE. ONCE A DRIVER'S MAPPING ASSIGNMENT 
BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS NOT REMOVED FROM THE 
QUEUE UNTIL THE UMR'S ARE SUCCESSFULLY ASSIGNED. THIS STRATEGY 
ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER'S 
WITH LARGE REQUESTS FOR UMR'S WILL NOT WAIT INDEFINITELY. 


INPUTS: 


R4=ADDRESS OF DEVICE SCB. 
R5=ADDRESS OF DEVICE UCB. 
(SP)=RETURN TO DRIVER'S CALLER. 


OUTPUTS: 


UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE 
ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB. 


NOTE: REGISTERS Rl, R2, AND R3 ARE PRESERVED ACROSS CALL. 


NOTE 


This routine pushes the address of 
routine $DQUMR+2 onto the stack before 
returning to the caller. A driver, 
therefore, should not use the stack for 
temporary data storage when calling this 
routine. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$STMP1 


SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 
This routine is in file MEMAP, It is used only for NPR devices’ that 
require UNIBUS Mapping Registers, support parallel operations, and 
have enabled 22-bit memory addressing. See Appendix B_ for a 
discussion of using this routine. 
Calling sequence: 

CALL SSTMP1 


Description: 


+ 


**-SSTMP1-SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY) 


THIS ENTRY CODE SETS UP AN ALTERNATE DATA STRUCTURE USED AS 
A UMR MAPPING ASSIGNMENT BLOCK AND CONTEXT STORAGE BLOCK, IN 
THE SAME MANNER AS SSTMAP USES THE FORK BLOCK AND MAPPING 

BLOCK IN THE SCB. THE FORMAT OF THE STRUCTURE IS AS FOLLOWS: 
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aa arom aia 4 WORDS USED FOR SAVING 
: ! DRIVER'S CONTEXT IN CASE 
! ! UMR'S CAN'T BE MAPPED 

: ! IMMEDIATELY. 

: ! 


! 

! 6 WORDS USED AS A UMR 

! MAPPING ASSIGNMENT BLOCK. 
J 
: 
' 


INPUTS: 
RO=ADDRESS OF THE DATA STRUCTURE DEPICTED ABOVE 
R4=ADDRESS OF DEVICE SCB 
R5=ADDRESS OF DEVICE UCB 

OUTPUTS: 


DATA STRUCTURE POINTERS SET UP FOR ENTRY TO SSTMP2 IN SSTMAP 


me we Se Ne Me Me Me NO TE NO NO Te NO Ne TO Me WO TO NH NO Ne TO NO Ne MO NO 


NOTE 


This routine pushes the address of 
routine SDQUMR+2 onto the stack before 
returning to the caller. A driver, 
therefore, should not use the stack for 
temporary data storage when calling this 
routine. 


EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS 


$SWSTK 


SWITCH STACKS 


This routine is in the file SYSXT. 


Calling sequence: 


SWSTKS label 


The special macro in RSXMC.MAC must be used. 


Description: 
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+ 


**kSSWSTK-SWITCH STACKS 


THIS ROUTINE IS CALLED FROM TASK LEVEL TO SWITCH TO THE SYSTEM 
STACK THUS INHIBITING TASK SWITCHING. THE CALLING TASK MUST BE 
PRIVILEGED IF RUNNING IN A MAPPED SYSTEM AND MAPPED TO THE EXEC. 
CONTROL IS PASSED HERE FROM DRDSP AFTER THE TRAP HAS OCCURRED AND 
SDIRSV HAS BEEN CALLED. 


CALLING SEQUENCE: 


EMT 376 ;TRAP TO SEMSST IN DRDSP 
«WORD ADDR ;ADDRESS FOR RETURN TO USER STATE 


INPUTS AT THIS POINT: 
R3=ADDRESS OF PC WORD OF TRAP ON STACK + 2 
MAPPED SYSTEM: 


22(SP)=PS PUSHED BY TRAP 

20(SP)=PC PUSHED BY TRAP 

16(SP)=SAVED R5 

14(SP)=SAVED R4 

12(SP)=SAVED R3 

10(SP)=SAVED R2 

06(SP)=SAVED Rl 

04(SP)=SAVED RO 

02(SP)=RETURN ADDRESS FOR SYSTEM EXIT 
00 (SP)=104376 


UNMAPPED SYSTEM: 


10(SP)=SAVED R3 
06 (SP)=SAVED R2 
04(SP)=SAVED Rl 
02(SP)=SAVED RO 
00(SP)=RETURN ADDRESS FOR SYSTEM EXIT 


OUTPUTS: 
THE USER IS CALLED BACK ON THE SYSTEM STACK WITH ALL REGISTERS 


PRESERVED. TO RETURN TO TASK LEVEL THE CALLER MERELY EXECUTES 
A RETURN. 


Note: Task registers are not modified. 
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CHAPTER 6 


INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES 


The first example that follows illustrates the procedures required to 
add a resident driver and resident data base to an RSX-11M system so 
that they can run on a system without support for loadable drivers and 
without multiuser protection. The driver in the example supports the 
punch capability of the PCll Paper Tape Reader/Punch. 


Section 6.3 gives a coding example from a resident driver that 
inhibits the automatic packet queuing in QIO processing in order to 
address-check and relocate a special user buffer. 


In addition to the examples shown in this chapter, you should review 
the source code for one or more standard DIGITAL-supplied drivers. 
Also, examine file SYSTB.MAC, which contains data structures created 
by SYSGEN. 


6.1 DEVICE DESCRIPTION 


The PCll Paper Tape Reader/Punch is capable of reading 8-hole, 
unoiled, perforated paper tape at 300 char/s, and punching tape at 50 
char/s. The system consists of a paper tape reader/punch and 
controller. A unit containing only a reader (PR11) is also available. 


In reading tape, a set of photodiodes translates the presence or 
absence of holes in the tape to logic levels representing ones and 


zeroes. In punching tape, a mechanism translates logic levels 
representing ones and zeroes to the presence or absence, respectively, 
of holes in the tape. Any information read or punched is 


parallel-transferred through the controller. When an address is 
Placed on the UNIBUS, the controller decodes the address and 
determines if the reader or punch has been selected. If one of the 
four device register addresses has been selected, the controller 
determines whether an input or an output operation should be 
performed. An input operation from the reader is initiated when the 
processor transmits a command to the paper tape reader status 
register. An output operation is initiated when the processor 
transfers a byte to the paper tape punch buffer register. 


The controller enables the PDP-l1l system to control the reading or 
punching of paper tape in a flexible manner. The reader can be 
operated independently of the punch; either device can be under 
direct program control or can operate without direct supervision 
(through the use of interrupts) so as to maintain continuous 
operation. 


INCLUDING A USER-WRITTEN DRIVER~--TWO EXAMPLES 


6.2 DATA BASE AND DRIVER SOURCE 
The simplicity of writing a conventional driver for RSX-11M is 
obscured by the volume of explanation required to cover the universal 


case. As you will see below, building a conventional driver is a 
Straightforward and modest undertaking. 


6.2.1 The Data Base 
The resident data base source shown below is’ self-explanatory. Take 
special note of the legal function mask words, starting at line 45. 
The standard function codes listed in Table 4-1 were used in creating 
the mask. Thus, the punch driver accepts the following I/O functions: 

e Cancel I/O (CAN) 

e Write Logical Block (WLB) 

e Attach Device (ATT) 

e@e Detach Device (DET) 

e Access File For Read/Write (ACW) 

e Access File For Read/Write/Extend (ACE) 

e Deaccess File (DAC) 

e Write Virtual Block (WVB) 


The CAN function is mandatory. The WLB function is the only transfer 
function actually supported. 


The ATT and DET functions are control functions. The three ATT/DET 
functions are legal for FCS and RMS compatibility, but are set to be 
no-ops. The WVB function is legal but is converted to WLB by QIO 
directive processing. 


The bit mask for each function is as follows: 


Function Function Code(octal) Mask(octal) Bit Range (decimal) 


CAN 0 000001 0-15. 
WLB 1 000002 0-15. 
ATT 3 000010 0-15. 
DET 4 000020 0-15. 
ACW 16 040000 0-15. 
ACE 17 100000 0-15. 
DAC 20 000001 16.-31. 
WVB 22 000004 16.~-31. 


The legal masks result from adding the O0-15(decimal) bit-range words 
to form a mask and all the 16-31l(decimal) bit-range words to form the 
second mask. 


The control, no-op, and ACP masks are created in an analogous fashion, 
matching bit positions with legal function code meanings. 


The complete set of mask words appears on lines 45 through 52 in the 
data structure source. 


INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES 


The function code selections for record-oriented devices are intended 
to match FCS and RMS requirements for file-structured devices. When 
FCS or RMS executes an Access For Write, it is simply marked as a 
no-op. This tends to minimize FCS and RMS device-dependent logic. 
Note also on line 84 that the controller number, which is encoded in 
the low byte of the interrupt vector PS word in RSX-11M, is set to 
zero. Finally, since the code represents a resident data base, note 
that lines 78 through 85 would be omitted for a loadable data base. 


1 - TITLE USRTB 

2 - IDENT /0l1/ 

3 

4; 

5 3; COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 

6 j 

7 ; THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
8 ; ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 

9 ; OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
10 ; AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC. 

ll ; 

12 ; THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
13 ; NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
14 ; EQUIPMENT CORPORATION. 

LS: 

16 ; DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 

17 ; OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC. 

Los 

19 ; VERSION O01 

20 ; 

21; T. J. PASCUSNIK 25-NOV-74 

220% 

23 ; CONTROL BLOCKS FOR PAPER TAPE PUNCH DRIVER 

24 ; 

25 ; MACRO LIBRARY CALLS 

26 ; 

27 
28 ~-MCALL DCBDFS,HWDDFS 
29 DCBDFS$ ;DEFINE DEVICE CONTROL BLOCK OFFSETSL 
30 HWDDF S$ ;DEFINE HARDWARE REGISTERS 

31 

32 3 ; 

33 ; PAPER TAPE PUNCH DEVICE DATA BASE 

34 ; 

35 ; PAPER TAPE PUNCH DEVICE CONTROL BLOCK 

36 ; 

37 SUSRTB:: 

38 PPDCB: ~WORD 0 ; LINK TO NEXT DCB 

39 ~WORD - PPO ;POINTER TO FIRST UCB 

40 ~ASCII /PP/ ;DEVICE NAME 
41 -BYTE 0,0 ; LOWEST AND HIGHEST UNIT NUMBERS COVERED 
42 ; BY THIS DCB 

43 -WORD PPND-PPST ;LENGTH OF EACH UCB IN BYTES 
44 ~WORD SPPTBL ;POINTER TO DRIVER DISPATCH TABLE 
45 - WORD 140033 ; LEGAL FUNCTION MASK CODES 0-15. 
46. »-WORD 30 ; CONTROL FUNCTION MASK CODES 0-15. 


1. Appendix C lists all macros that exist in RSX-11M to generate 
control block offsets. 
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47 ~WORD 140000 :NO-P'ED FUNCTION MASK CODES 0-15. 

48 -WORD 0 ACP FUNCTION MASK CODES 0-15. 

49 -WORD 5 ; LEGAL FUNCTION MASK CODES 16.-31. 

50 ~WORD 0 ;CONTROL FUNCTION MASK CODES 16.-31. 
51 -WORD 1 s;NO-OP'ED FUNCTION MASK CODES 16.-31l. 
52 -WORD 4 ;ACP FUNCTION MASK CODES 16.-31. 

53 > 

54 ; PAPER TAPE PUNCH UNIT CONTROL BLOCK 

55: ¢ 

56 .PPO:: 

57 PPST=. 

58 -~WORD PPDCB ;BACK POINTER TO DCB 

59 -WORD ~-2 s;POINTER TO REDIRECT UNIT UCB 

60 ~ BYTE UC. ATT, 0 sCONTROL PROCESSING FLAG (PASS CONTROL 
61 : ON ATTACH/DETACH), UNIT STATUS 

62 ~ BYTE 0,0 ; PHYSICAL UNIT NUMBER, UNIT STATUS EXTENSION 
63 -WORD DV. REC 7;FIRST DEVICE CHARACTERISTICS WORD 

64 7 (RECORD-ORIENTED DEVICE) 

65 ~WORD 0 ;SECOND DEVICE CHARACTERISTICS WORD 
66 H (FOR INTERNAL USE BY DRIVER) 

67 -WORD 0 ;THIRD DEVICE CHARACTERISTICS WORD 

68 ; (FOR INTERNAL USE BY DRIVER) 

69 -WORD 64. ;FOURTH DEVICE CHARACTERISTICS WORD 
70 ; (DEFAULT BUFFER SIZE IN BYTES) 

71 -~WORD PPSCB ;POINTER TO SCB 

72 ~WORD 0 ;TCB ADDRESS OF ATTACHED TASK 

73 - BLKW 1 ;RELOCATION BIAS OF BUFFER OF CURRENT 
74 ; I/O REQUEST 

75 ~ BLKW 1 ;ADDRESS OF BUFFER OF CURRENT I/O REQUEST 
76 - BLKW 1 ;BYTE COUNT OF CURRENT I/O REQUEST 

77 PPND=. 

yg = ee 

79 ; PAPER TAPE PUNCH INTERRUPT VECTOR 

80 ; 

81 - ASECT 

82 .=74 

83 -WORD SPPINT ;ADDRESS OF INTERRUPT ROUTINE 

84 - WORD PR7!0 ; INTERRUPT AT PRIORITY 7 (CONTROLLER=0) 
85 » PSECT 

86 ; 

87 ; PAPER TAPE PUNCH STATUS CONTROL BLOCK 

88 ; 

89 PPSCB: -WORD 0 ;CONTROLLER I/O QUEUE LISTHEAD 

90 : (POINTER TO FIRST ENTRY) 

91 -WORD ~-2 7 (POINTER TO LAST ENTRY) 

92 ~BYTE PR4,74/4 ;DEVICE PRI, INTERRUPT VECTOR ADDRESS/4 
93 ~BYTE 0,4 ;CURRENT AND INITIAL TIMEOUT COUNTS 
94 BYTE 0,0 ;CONTROLLER INDEX AND STATUS 

95 H (O=IDLE, 1=BUSY) 

96 ~WORD 177554 ; ADDRESS OF CONTROL STATUS REGISTER 
97 . BLEW 1 ;ADDRESS OF CURRENT I/O PACKET 

98 « BLKW 4 ;FORK BLOCK ALLOCATION 

99 
100 .- END 


6.2.2 Driver Code 


The code shown below for the punch capability of the PCll is typical 
for a conventional driver. In fact, many of the descriptive comments 
can be used as a template and easily tailored to a driver for another 
device. 
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The structure of the driver follows the standard RSX-11M form, being 
separated into processing code for the following: 


e Initiator 
e Power failure 
e Interrupt 
e Time-out 
e Cancel I/0 
The driver itself services only Write Logical, Attach, and Detach I/0 


functions. Attach and Detach resuit in the punching of 170. nulls 
each for header and trailer. 


Power failure and cancel I/O are handled by means of device time-out, 
as is the device-not-ready condition. 


The driver uses the following Executive services: 


SINTXT 
SGT PKT 
SGTBYT 
SDVMSG 


SINTSV is used indirectly; it is called by INTSVS (line 165). See 
Section 4.3. 


Comments beginning with ';;;' indicate that the instruction is being 
executed at a priority level greater than or equal to 4. 


The code contained in lines 139-141 is used to inhibit the punching of 
a trailer on ATT/DET if the task is being aborted. This is especially 
desirable when the device is not ready (for example, out of paper 
tape) and the system has generated the DET function for the aborting 
process. 


Le -TITLE PPDRV 

Ze ~IDENT /02/ 

ee 

4. ; 

5. 3; COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS. 
Ga: “2 

7. 3; THIS SOFTWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE 
8. ; ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION 
9. ; OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT 
10. ; AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC. 

a ee 
12. ; THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT 
13. ; NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL 
14. ; EQUIPMENT CORPORATION. 
Paw s 
16. ; DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY 
17. ; OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC. 
LOer. 3 
19. ; VERSION 02 
20%. ¢ 
Zi. 3; T. J. PASCUSNIK 25-NOV-74 
226-3 
23. ; MODIFIED BY: 
24. ? 
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C. A. ANDERS 15-MAR-76 


T. J. PASCUSNIK 4-APR-76 


PC1ll PAPER TAPE PUNCH DRIVER 


MACRO LIBRARY CALLS 


me Tse MO Be TE NS We Ve VO WH WH We WE 


CA001 -- ADDITION OF LOADABLE DRIVER SUPPORT. 


TP031 -- EXECUTIVE DATA STRUCTURE CHANGES. 


.MCALL ABODFS,HWDDFS, PKTDFS, TCBDFS$ 


ABODFS 
HWDDF $ 
PKTDFS$ 
TCBDFS$ 


EQUATED SYMBOLS 


ue me Me Re BO 


WAIT=100000 
ABORT=40000 
TRAIL=200 


LOCAL DATA 


~e Se Me Me Ne 


CNTBL: .BLKW PS$P1l 


-IF GT PSSP11-1 
TEMP: . BLKW it 


» ENDC 


DRIVER DISPATCH TABLE 


se we te 


SPPTBL:: .WORD PPINI 
.WORD PPCAN 
.WORD PPOUT 
.WORD PPPWF 


+ 


me we “Se te Me MO Me Ne Ne 


;DEFINE TASK ABORT CODES 

;DEFINE HARDWARE REGISTER SYMBOLS 
;DEFINE I/O PACKET OFFSETS 

;DEFINE TASK CONTROL BLOCK OFFSETS 


;WAITING FOR DEVICE TO COME ON-LINE (1=YES) 
; ABORT CURRENT I/O REQUEST (1=YES) 
;CURRENTLY PUNCHING TRAILER (1=YES) 


;ADDRESS OF UNIT CONTROL BLOCK 


7 TEMPORARY STORAGE FOR CONTROLLER NUMBER 


;DEVICE INITIATOR ENTRY POINT 
;CANCEL I/O OPERATION ENTRY POINT 
;DEVICE TIMEOUT ENTRY POINT 
;POWERFAIL ENTRY POINT 


s 
& 
° 
’ 


PAPER TAPE PUNCH STATUS WORD BIT DEFINITIONS 


CONTROLLER IMPURE DATA TABLES (INDEXED BY CONTROLLER NUMBER) 


CA00] 
CAO00] 


**-PPINI-PC1l PAPER TAPE PUNCH CONTROLLER INITIATOR 


THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 

IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECU- 
TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, 
IS MADE TO DEQUEUE THE NEXT I/O REQUEST. 
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, 
ATION IS INITIATED, A RETURN TO THE CALLER IS THEN EXECUTED. 


THEN AN ATTEMPT 
ELSE A RETURN TO THE CALLER IS 
THEN THE NEXT I/0 OPER- 


89. 
90. 
91. 
92. 
93. 
94. 
95% 
96. 
97. 
98. 
99. 
100. 
101. 
102. 
103. 
104. 
105. 
106. 
107. 
108. 
109. 
110. 
nip le 
12 
F136 
114, 
LLOds 
116. 
Lats 
118% 
119. 
120. 
121. 
122. 
123. 
124. 
125. 
126. 
127. 
128, 
129. 
130. 
T3L. 
132, 
133% 
134. 
135. 
136. 
137. 
138. 
139. 
140. 
Lal s 
142, 
143% 
144, 
145. 
146, 
147. 
148, 
149. 
L350. 
eosen 
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INPUTS: 


OUTPUTS: 


we we WA WO TO Se NO Me NO NS GO 


R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 


IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT- 
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/0 OPER- 
ATION IS INITIATED. 


~ENABL LSB 


PPINI: CALL 
BCS 


WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 
WD. 


me Ne Ne Se Ne Se Ne Me MP Ne Se Se MO Ne Ne Ne Ne MO Ne NO NO We NA NO NE NO Ne Ne Ne 


MOV 
CLR 
CMPB 
BEQ 
MOV 
BIT 
BNE 
BIS 


MOV 
10S: BIS 
TST 
BMI 
20S: BIC 
MOVB 
MOV 


SGT PKT 7;GET AN I/O PACKET TO PROCESS 
PPPWF 7IF CS CONTROLLER BUSY OR NO REQUEST 


THE FOLLOWING ARGUMENTS ARE RETURNED BY SGTPKT: 


R1=ADDRESS OF THE I/O REQUEST PACKET. 

R2=PHYSICAL UNIT NUMBER OF THE REQUEST UCB. 
R3=CONTROLLER INDEX. 

R4=ADDRESS OF THE STATUS CONTROL BLOCK. 

R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 


PAPER TAPE PUNCH I/O REQUEST PACKET FORMAT: 


-- I/O QUEUE THREAD WORD. 

-- REQUEST PRIORITY, EVENT FLAG NUMBER. 

-- ADDRESS OF THE TCB OF THE REQUESTER TASK. 

-- POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER. 

-~ CONTENTS OF THE FIRST LUN WORD IN REQUESTER TASK HEADER (UCB). 
-- I/O FUNCTION CODE (IO.WLB, IO.ATT OR IO.DET). 

-- VIRTUAL ADDRESS OF I/O STATUS BLOCK. 

-- RELOCATION BIAS OF I/O STATUS BLOCK. 

-- I/O STATUS BLOCK ADDRESS (REAL OR DISPLACEMENT + 140000). 
-- VIRTUAL ADDRESS OF AST SERVICE ROUTINE. 

-- RELOCATION BIAS OF I/0 BUFFER. 

-- BUFFER ADDRESS OF I/O TRANSFER. 

-- NUMBER OF BYTES TO BE TRANSFERED. 

-- NOT USED. 

-- NOT USED. 

-- NOT USED. 

-- NOT USED. 


R5,CNTBL (R3) ;SAVE UCB POINTER FOR INTERRUPT ROUTINE 
U.CW2(R5) ;CLEAR ALL SWITCHES 

I. FCN+1(R1),#IO.WLB/256. ;WRITE LOGICAL BLOCK FUNCTION? 
10$ ;IF EQ YES 


I.TCB(R1),RO ;GET REQUESTOR TCB ADDRESS 
#T2.ABO,T.ST2(RO) ;TASK BEING ABORTED? 7 TPO31 
65$ 7IF NE YES - DON'T PUNCH TRAILER 


#TRAIL,U.CW2(R5) ;OTHERWISE FUNCTION IS ATTACH OR DETACH 
; SET FLAG TO PUNCH TRAILER 

#170.,U.CNT(R5) ;SET COUNT FOR 170 NULLS 

#WAIT,U.CW2(R5) ;ASSUME WAIT FOR DEVICE OFF LINE 

@S.CSR(R4) ;DEVICE OFF LINE? 

80$ ;IF MI YES 

#WAIT,U.CW2(R5) ;DEVICE ON LINE, CLEAR WAIT CONDITION 

S.ITM(R4),S.CTM(R4) ;SET TIMEOUT COUNT 

#100,@S.CSR(R4) ;ENABLE INTERRUPTS 
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187. 
188. 
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190. 
191. 
192. 
193. 
194, 
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PPPWF: 


SPPINT:: 


65S: 
70$: 


me me Me Ge 


PPOUT: 


80S: 


INCLUDING A 


RETURN 


CLRB 
CLRB 
MOV 
MOV 
BPL 
MOV 
ASL 
BMI 
TST 
BPL 
MOV 
MOVB 
DECB 
BNE 
MOVB 
CALLR 


PP, PR4, PS$P11 
U.SCB(R5),R4 


S.ITM(R4),S.CTM( 


S.CSR(R4),R4 


(R4)+,U.CW3(R5) 


60$ 
#1,U.CNT(R5) 
50S 

U.CW2(R5) 

30$ 

(R4) 

40s 

SGTBYT 

(SP)+, (R4) 
SINTXT 
U.CNT(R5) 
~-(R4) 

SFORK 
U.SCB(R5),R4 
S.PKT(R4),R1 
I. PRM+4(R1),R1 
U.CNT(R5),R1 
#IS.SUC&377,R0 
U.CW3(R5) 

70$ 

#1E. VER&377, RO 
SIODON 

PPINI 


DEVICE TIMEOUT RESULTS IN A NOT 
MINUTE. TIMEOUTS ARE CAUSED BY POWERFAILURE AND PUNCH FAULT CONDITIONS. 


@S.CSR(R4) 

PS 
#I1E.DNR&377, RO 
U.CW2(R5),R1 
70$ 
#IE.ABO&377, RO 
Rl 

70$ 

@S.CSR(R4) 

20$ 

#T .NDNR, RO 
#1,S.CTM(R4) 
S.STS(R4) 
PPPWF 
#15.,S.STS(R4) 
SDVMSG 


»-DSABL LSB 


USER-WRITTEN DRIVER--TWO EXAMPLES 


POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND THEREFORE CAUSES 
NO IMMEDIATE ACTION ON THE DEVICE. THIS IS DONE TO AVOID A RACE CONDITION 
THAT COULD EXIST IN RESTARTING THE I/O OPERATION 


me 


7 
; **-SPPINT-PC11 PAPER TAPE PUNCH CONTROLLER INTERUPTS 
i 


REF LABEL 

GENERATE INTERRUPT SAVE CODE ; CAO0O1 
GET ADDRESS OF STATUS CONTROL BLOCK 
77;7;RESET TIMEOUT COUNT 
POINT R4 TO CONTROL STATUS REGISTER 
SAVE STATUS 

I ERROR 

DECREMENT CHARACTER COUNT 
IF CS, THEN DONE 

CURRENTLY PUNCHING TRAILER? 
I 

L 

B 

G 

L 

E 

R 

D 

C 


OAD NULL INTO OUTPUT REGISTER 
RANCH TO LOAD IT 

ET NEXT BYTE FROM USER BUFFER 
OAD BYTE INTO OUTPUT REGISTER 
XIT FROM INTERRUPT 

ESET BYTE COUNT 

ISABLE PUNCH INTERRUPTS 

REATE SYSTEM PROCESS 
INT R4 TO SCB 
OINT Rl TO I/O PACKET 

AND PICK UP CHARACTER COUNT 
CALCULATE CHARACTERS TRANSFERRED 
ASSUME SUCCESSFUL TRANSFER 

EVICE ERROR? 


e 
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NITIATE I/O COMPLETION 
RANCH BACK FOR NEXT REQUEST 
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D 
I 
UNRECOVERABLE HARDWARE ERROR CODE 
I 
B 


READY MESSAGE BEING PUT OUT 4 TIMES A 


7;DISABLE PUNCH INTERRUPT 
7;ALLOW INTERRUPTS 
ASSUME DEVICE NOT READY ERROR 
ARE WE WAITING FOR DEVICE READY? 
IF PL NO, TERMINATE 1/0 REQUEST 
ASSUME REQUEST IS TO BE ABORTED 
ABORT REQUEST? 
IF MI YES 
PUNCH READY? 
IF PL YES 
SET FOR NOT READY MESSAGE 

SET TIMEOUT FOR 1 SECOND 

TIME TO OUTPUT MESSAGE? 

IF NE NO 

ET TO OUTPUT NEXT MESSAGE IN 15. 
OUTPUT MESSAGE AND RETURN 
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SECONDS 


~e 


. 
f 
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216. 

217. ; 

218. ; CANCEL I/O OPERATION-FORCE I/O TO COMPLETE IF DEVICE IS NOT READY 
219. ; 

220. 

221. PPCAN: CMP R1,1I.TCB(RO) 33;REQUEST FOR CURRENT TASK? 

222. BNE 10$ 7331F NE NO 

223. BIS #ABORT,U.CW2(R5) 3;;;SET FOR ABORT IF DEVICE NOT READY 
224. 10S: RETURN 733 

225. 

226. - END 


Some drivers need to handle user buffers in addition to the buffer 
that the Executive address-checks and relocates in a normal transfer 
request. Address checking and relocation operations must take place 
in the context of the task issuing the I/O request, because the 
mapping registers are set for the issuing task. However, in the 
normal driver interface, the task context after the call to SGTPKT is 
not, in general, that of the issuing task. 


Thus, drivers that need to handle special buffers must be able to 
reference the I/O packet before it is queued, while the context of the 
issuing task is still intact. 


The following coding excerpts from a standard RSX-l11M driver (the 
AFC1l1l driver) illustrate the handling of a special user buffer. The 
key points are: 


@ The UC.QUE bit has been set in the control byte (U.CTL) of the 
UCB for each device/unit. (This is not shown in the coding 
excerpts below.) 


e The routine that is referenced as the initiator entry point in 
the driver dispatch table performs the following actions: 


1. Picks up the user virtual address and conditionally 
address-checks it. 


2. Relocates the virtual address, storing the result back 
into the packet. 


3. Inserts the packet into the I/O queue and falls’ through 
to the entry point AFINI, which calls S$GTPKT. 


e The driver propagates its own execution by branching back to 
AFINI to call $GTPKT. 


DRIVER DISPATCH TABLE 


me Me MO 


SAFTBL::.WORD AFCHK ;DEVICE INITIATOR ENTRY POINT 
eWORD AFCAN ;CANCEL I/O OPERATION ENTRY POINT 
~-WORD AFOUT ;DEVICE TIMEOUT ENTRY POINT 
-WORD AFPWF ;POWERFAIL ENTRY POINT 


INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES 


+ 


**-AFCHK-AFC11 ANALOG TO DIGITAL CONVERTER CONTROLLER PARAMETER CHECKING 


THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST 

IS RECEIVED FOR THE AFC11 ANALOG TO DIGITAL CONVERTOR. AFC11 I/O REQUESTS 
CONTAIN DEVICE DEPENDENT INFORMATION THAT MUST BE CHECKED IN THE CONTEXT 

OF THE ISSUING TASK. THEREFORE THE I/O REQUEST IS NOT QUEUED BEFORE CALLING 
THE DRIVER. 


INPUTS: 


R1=ADDRESS OF THE I/O REQUEST PACKET. 
R4=ADDRESS OF THE STATUS CONTROL BLOCK. 
R5=ADDRESS OF THE UCB OF THE CONTROLER TO BE INITIATED. 


OUTPUTS: 


THE CONTROL BUFFER IS ADDRESS CHECKED TO DETERMINE WHETHER IT LIES 
WITHIN THE ISSUING TASK'S ADDRESS SPACE. IF THE ADDRESS CHECK 
SUCCEEDS, THEN THE CONTROL BUFFER ADDRESS IS RELOCATED AND STORED 
IN THE I/O PACKET, THE I/O PACKET IS INSERTED IN THE CONTROLLER 
QUEUE, AND THE DEVICE INITIATOR IS ENTERED TO START THE CONTROLLER. 
ELSE AN ILLEGAL BUFFER STATUS IS RETURNED AS THE FINAL I/O STATUS 
OF THE REQUEST. 


me te Ge Te Te TO Ne Be We WO We We Ge VO We Ns We Be BE We WH NWO We We WS 


AFCHK: MOV R1,R3 ;COPY ADDRESS OF I/0 PACKET 
MOV I.PRM+6(R3),RO ;GET VIRTUAL ADDRESS OF CONTROL BUFFER 


-IF DF ASSCHK!MSSMGE 


MOV I.PRM+4(R3),R1 ;SET LENGTH OF BUFFER TO CHECK 
CALL SAC HCK ;ADDRESS CHECK CONTROL BUFFER 
BCC 10$ 7IF CC ADDRESS OKAY 
MOV #IE.SPC&377,RO ;SET ILLEGAL BUFFER STATUS 
CALLR SIOFIN ;FINISH I/O OPERATION 
- ENDC 

10$: CALL SRELOC RELOCATE CONTROL BUFFER ADDRESS 
MOV R1l,1I.PRM+6(R3) ;SET RELOCATION BIAS OF CONTROL BUFFER 
MOV R2,I1.PRM+10(R3) ;SET ADDRESS OF CONTROL BUFFER 
MOV R3,R1 ;SET ADDRESS OF I/O PACKET 
MOV R4,R0 ;SET ADDRESS OF I/O QUEUE LISTHEAD 
CALL SQINSP ;INSERT I/O PACKET IN REQUEST QUEUE 
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+ 


**-AFINI-AFC11 ANALOG TO DIGITAL CONVERTOR CONTROLLER INITIATOR 


THIS ROUTINE IS ENTERED FROM THE QUEUE I/O DIRECTIVE WHEN AN I/0 REQUEST 

IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECU- 
TION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT 
IS MADE TO DEQUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS 
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPER- 
ATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED. 


INPUTS: 
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED. 
OUTPUTS: 
IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT 


ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER- 
ATION IS INITIATED. 


-ENABL LSB 
AFINI: CALL SGT PRT ;GET AN I/O PACKET TO PROCESS 
BCS AFCAN ;IF CS CONTROLLER BUSY OR NO REQUEST 
7I1/O CANCEL (AFCAN) IS A NO-OP FOR AFC11 
7 . 
? e 
7 . 
CALL SIODON sFINISH I/O OPERATION 
BR AFINI 7GO AGAIN 


ue te MO 


APPENDIX A 


DEVELOPMENT OF THE ADDRESS DOUBLEWORD 


A.1 INTRODUCTION 


You can generate an RSX-11M system as a mapped or an unmapped system. 
Mapped systems can accommodate configurations whose maximum physical 
memory is 4096K bytes. Individual tasks, however, are limited to 64K 
bytes. The addressing in a mapped system uses virtual addresses and 
memory mapping hardware. I/O transfers, however, use physical 
addresses 18 bits in length. Since the PDP-11 word size is 16 bits, 
some scheme is necessary to represent an address internally until it 
is actually used in an I/O operation. The choice was made to encode 
two words as the internal representation of a physical address, and to 
transform virtual addresses for I/0 operations into the internal 
doubleword format. 


A.2 CREATING THE ADDRESS DOUBLEWORD 


For unmapped systems, the doubleword is simply a word of zeros 
followed by a word containing the real address. 


On receipt of a QIO directive for mapped systems, the buffer address 
in the DPB, which contains a task virtual address, is converted to 
address doubleword format. 
The virtual address in the DPB is structured as follows: 

Bits 0-5 Displacement in terms of 32-word blocks 


Bits 6-12. Block number 


Bits 13.-15. Page Address Register (PAR) number 


DEVELOPMENT OF THE ADDRESS DOUBLEWORD 


The internal RSX-11M translation restructures this virtual address 
into an address doubleword as follows: 


Ls 


The relocation base contained in the PAR specified by the PAR 
number in the virtual address in the DPB is added to the 
block number in the virtual address. The result becomes’ the 
first word of the address doubleword. It represents the nth 
32-word block in a memory viewed as a collection of 32-word 
blocks. Note that at the time the address doubleword is 
computed, the user issuing the QIO directive is mapped into 
the processor's memory management registers. 


The second word is formed by placing the 
displacement-in-block (bits 0-5 of virtual address) into bits 
0-5. The block number field was accommodated in the first 
word and bits 6-12. are cleared. Finally, a 6 is placed in 
bits 13.-15. to enable use of PAR #6, which the Executive 
uses to service I/O for program transfer devices. 


For non-processor request (NPR) devices, the driver 
requirements for manipulating the address doubleword are 
direct and are discussed with the description of U.BUF in 
Section 4.1.4.1. 


APPENDIX B 


DRIVERS FOR NPR. DEVICES USING EXTENDED MEMORY 


You must build special features into drivers for nonextended memory 
NPR devices attached to a PDP-1l processor with extended-memory 
support (22-bit addressing). 


Nonextended memory NPR devices on the PDP-1l processor must’ perform 
I/O transfers by means of UNIBUS Mapping Registers (UMRS), as 
described in the PDP-1l Processor Handbook. One UMR is’ required for 
each 4K words involved in the transfer--as specified by the contents 
of U.CNT in the UCB. When multiple UMRs are required for a transfer, 
they must be contiguous. 


A driver can be assigned UMRs through one of three procedures. These 
procedures involve the following: 


1. Dynamically allocating UMRs for the duration of the data 
transfer 


2. Dynamically allocating UMRs for longer periods of time 


3. Statically allocating UMRs during system generation 


NOTE 


In large systems, using the second = and 
third procedures above to hold UMRs for 
longer periods than necessary can result 
in the blocking of other drivers and a 
reduction in system throughput. 


B.1 CALLING SSTMAP AND SMPUBM OR SSTMP1 AND $MPUB1 


To obtain UMRs through use of the SSTMAP and S$MPUBM or S$STMP1 and 
SMPUB1 routines, a driver must: 


1. If it uses $STMAP and SMPUBM or SSTMP1 and SMPUB1, allocate 
six additional words for a mapping register assignment block 
at the end of the device's SCB (at S.MPR). If it uses SSTMP1 
and SMPUB1, also provide a 10-word block. 


2. Call the routine S$STMAP or SSTMP1 (set up UNIBUS mapping 
address) after getting the I/O packet. 


3. Call the routine SMPUBM or SMPUB1 (map UNIBUS to memory) 
before initiating a transfer. 


DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY 


These requirements are detailed in the following three subsections. 


Note that these routines are only required when the driver is 
performing a data transfer. 


B.1.1 Allocating a Mapping Register Assignment Block 


The status control block (SCB) of an NPR device requires an additional 
Six words. This 6-word mapping register assignment block is located 
at S.MPR, at the end of the SCB. It does not have to be initialized. 
Any initial contents are simply overwritten. 


The following example shows the allocation of a mapping register 
assignment block. The code is conditional on. the result of an AND 
operation on the two symbols MSSEXT and MSSMGE (representing extended 
memory support and memory management unit support, respectively). 


-IF DF MSSEXT&MSSMGE 
- BLKW 6 ; UMR WORK AREA 
- ENDC 


If the driver does not support parallel NPR operations requiring UMR 
mapping, it calls $STMAP and SMPUBM. If the driver supports parallel 
NPR operations requiring UMR mapping, it must call SSTMP1 and SMPUB1. 
In the latter situation, the six additional words starting at S.MPR in 
the SCB are not used but must still be present. In addition, the 
driver must provide a 10-word mapping register assignment block for 
each data transfer to be mapped, as specified in the description of 
SSTMP1 in Chapter 5. 


B.1.2 Calling $STMAP or $STMP1 


In the coding at the initiator entry point, after the call to $GTPKT, 
the NPR device driver must call the routine $STMAP or $STMP1. These 
routines dynamically allocate required UMRs. If UMRs~ are not 
available immediately, the driver is blocked. Such blocking, if it 
occurs, is completely transparent to the driver. The driver resumes 
processing at fork level when the UMRs have been allocated. The 
register returns are absolutely identical whether or not blocking has 
occurred. 


SSTMAP or SSTMP1 stores into U.BUF and U.BUF+2 (in the UCB) a UNIBUS 
address that causes the appropriate UMR to be selected for mapping the 
transfer. The call to SSTMAP or SSTMP1 must be conditional on MSSEXT 
and MSSMGE. 


Because S$STMAP and S$STMP1 push the address of routine $DQUMR+2 onto 
the stack before returning to the caller, the driver should not use 
the stack for temporary data storage when it calls $STMAP or $STMP1. 
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B.1.3 Calling SMPUBM or S$MPUB1 


Before executing the transfer, the driver must call SMPUBM or SMPUB1. 
These routines get the buffer's 22-bit physical address, and load the 
UNIBUS mapping registers so that transfers are mapped directly to the 
task's space. The call to SMPUBM or SMPUB1 must be conditional on 
MSSEXT and MSSMGE. 


If the driver calls SSTMAP and SMPUBM, the UMRs allocated to it are 
deallocated during the call to SIODON or S$IOALT. If the driver calls 
SSTMP1 and SMPUBI1, it must call $DEUMR to deallocate any allocated 
UMRs before calling S$IODON or SIOALT. 


B.2 CALLING SASUMR AND $DEUMR 


Some drivers may not require UMRs to be allocated all of the time, and 
yet require UMRs for periods of time longer than the normal time frame 
between SGTPKT and SIODON (or SIOALT). In such cases, there is a 
second procedure for allocating UMRs. 


By using the Executive routines SASUMR and S$DEUMR, a driver can 
dynamically allocate, retain over a desired time frame, and deallocate 
UMRs. Refer to Section 5.3 for a description of the SASUMR and SDEUMR 
routines. 


Similar to the SSTMAP/SMPUBM procedure, uSing SASUMR and S$DEUMR also 
requires the allocation of a 6-word mapping register assignment block. 
In this instance, however, the block must not be located at offset 
S.MPR in the SCB. SIODON or SIOALT, when called, will attempt to 
deallocate the UMRs of a block found at location S.MPR. To avoid 
this, the mapping register assignment block could, for convenience, be 
located at S.MPR+2. Alternatively, it could be dynamically allocated 
from the pool. Figure B-l details the format of the 6-word block. 


M.LNK Link Word 

M.UMRA Address of first assigned UMR 

M.UMRN Number of assigned UMRs *4 

M.UMVL Low 16 bits mapped by first assigned UMR 
M.UMVH High 6 bits of High 2 bits mapped by 
M.BFVH physical buffer address UMR (in bits 4 and 5) 
M.BFVL Low 16 bits of physical buffer address 


ZK-226-81 


Figure B-l Mapping Register Assignment Block 
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B.3 STATICALLY ALLOCATING UMRS DURING SYSTEM GENERATION 


You can statically assign UMRs during system generation. For systems 
with extended memory support and memory management unit support, the 
system generation procedure defines the symbol NSSUMR equal to a fixed 
number of UMRs, multiplied by 4, that are statically assigned to the 
system. Before assembling the Executive, you can cause the static 
allocation of an additional number of UMRs by editing file RSXMC.MAC. 
The value of the symbol NSSUMR can then be increased to represent the 
additional number of desired UMRs multiplied by 4. 


RSXMC.MAC further defines the following three symbols, which describe 
the first UMR statically allocated during system generation: 


USSMRN is the I/O page address of the first UMR_ register 
available for allocation to the user. 


USSMLO represents the low-order 16 bits of the 18-bit UNIBUS 
address mapped by this UMR. 


USSMHI represents the high-order two bits of the 18-bit UNIBUS 
address. These two bits are in bit positions 4 and 5. 


These three symbols are not used by the system itself. They are 
available for the user's information. 


APPENDIX C 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


This appendix describes the system data structures listed in Table 
C=1. 


The data structures are defined by macros in the Executive macro 
library. To reference any of the data structure offsets from your 
code, include the macro name in an .MCALL directive and invoke the 
macro. For example: 


»~MCALL DCBDFS 
DCBDFS$ ;Define DCB offsets 


NOTE 


All physical offsets and bit definitions 
are subject to change in future releases 
of the operating system. Code that 
accesses system data structures should 
always use the symbolic offsets rather 
than the physical offsets. 


The first two arguments, <:> and <=>, make all definitions global. If 
they are left blank, the definitions will be local. The SYSDEF 
argument causes the variable part of a data structure to be defined. 


All of these macros are in the Executive macro library 
LB: [1,1 ]EXEMC.MLB. All except ITBDFS and MTADFS are also in the 
Executive definition library LB: [{1,1]EXELIB. OLB. 


ABODFS 


CLKDFS 
DCBDF$ 
EPKDFS 


F11DFS$ 


HDRDFS 


HWDDFS 


ITBDFS$ 
LCBDFS$ 


MTADFS 


PCBDF$ 


PKT DFS 


SCBDF$ 


UCBDFS$ 
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Table C-l 
Summary of System Data Structure Macros 


<2>,<=> 


<2:>,<=> 
<2 >y <=> 
<:>,<=> 


<:>,<=>,SYSDEF 


<3>,<=> 


<2>,<=> 


<:>,<=>,SYSDEF 
<2>,<=> 


<2>,<=> 
€:>,<=>,SYSDEF 


<2>,<=> 


€3>,<=>,SYSDEF 


<:>,<=>, TTDEF, SYS DEF 


Task abort and termination 
notification message codes 


Clock queue control block 

Device Control Block 

Error message block 

Files-ll data structures (volume 
control block, mount list entry, 
file control block, file window 
block, locked block list node) 


Task header and window block 


Hardware register addresses’ and 
feature mask definitions 


Interrupt transfer block 
Logical assignment control block 


ANSI mag tape data structures 
(volume Set control block) 


Partition control block and 
attachment descriptor 


I/O packet, AST control block, 
offspring control block, group 
global event flag control block, 
and CLI parser block 

Task Control Block 


Unit Control Block 
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ABODF$ 

ABODFS 
; 
; TASK ABORT CODES 
e 
; NOTE: S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS 
f 
S.CACT=-4, ;TASK STILL ACTIVE 
S.CEXT=-2. ;TASK EXITTED NORMALLY 
S.COAD=0. ;ODD ADDRESS AND TRAPS TO 4 
S.CSGF=2. ;SEGMENT FAULT 
S.CBPT=4. ;BREAK POINT OR TRACE TRAP 
S.CIOT=6. ;1IOT INSTRUCTION 
S.CILI=8. ;ILLEGAL OR RESERVED INSTRUCTION 
S.CEMT=10. ;NON RSX EMT INSTRUCTION 
S.CTRP=12. ;TRAP INSTRUCTION 
S.CFLT=14. 711/40 FLOATING POINT EXCEPTION 
S.CSST=16. 7SST ABORT-BAD STACK 
S.CAST=18. ;AST ABORT-BAD STACK 
S.CABO=20. ;ABORT VIA DIRECTIVE 
S.CLRF=22. TASK LOAD REQUEST FAILURE 
S.CCRF=24. ;TASK CHECKPOINT READ FAILURE 
S. IOMG=26. ;TASK EXIT WITH OUTSTANDING 1/0 
S.PRTY=28. ;TASK MEMORY PARITY ERROR 
S.CPMD=30. ;TASK ABORTED WITH PMD REQUEST 
S.CINS=32. ;TASK INSTALLED IN TWO SYSTEMS 
i 
; TASK TERMINATION NOTIFICATION MESSAGE CODES 
f 
T.NDNR=0 ;DEVICE NOT READY 
T.NDSE=2 ;DEVICE SELECT ERROR 
T.NCWF=4 ; CHECKPOINT WRITE FAILURE 
T.NCRE=6 ;CARD READER HARDWARE ERROR 
T.NDMO=8,. ;DISMOUNT COMPLETE 
T.NUER=10. ;UNRECOVERABLE ERROR 
T.NLDN=12. LINK DOWN (NETWORKS) 
T.NLUP=14. LINK UP (NETWORKS) 
T.NCFI=16. ;CHECKPOINT FILE INACTIVE 
T.NUDE=18. ;UNRECOVERABLE DEVICE ERROR 
T.NMPE=20. ;MEMORY PARITY ERROR 
T.NKLF=22. ;UCODE LOADER NOT INSTALLED 
T.NDEB=24. ;TASK HAS NO DEBUGGING AID 
T.NRCT=26. ;REPLACEMENT CONTROL TASK NOT INSTALLED 
T.NWBL=28. ;WRITE BACK CACHING DATA LOST 


;UNIT WRITE LOCKED 
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CLKDF$ 


000000 
000002 
000003 
000004 
000006 


000012 
000014 
000016 


000012 
000016 


000012 
000016 
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CLKDFS 


CLOCK QUEUE 


CLOCK QUEUE 


CONTROL BLOCK OFFSET DEFINITIONS 


CONTROL BLOCK 


THERE ARE SIX TYPES OF CLOCK QUEUE CONTROL BLOCKS. EACH CONTROL 
BLOCK HAS THE SAME FORMAT IN THE FIRST FIVE WORDS AND DIFFERS IN 
THE REMAINING THREE. 


THE FOLLOWING CONTROL BLOCK TYPES ARE DEFINED: 


.MRKT=0 
. SCHD=2 
. SSHT=4 
.SYST=6 
.SYTK=8. 
.CSTP=10. 


CLOCK QUEUE 


;MARK TIME REQUEST 

;TASK REQUEST WITH PERIODIC RESCHEDULING 
7;SINGLE SHOT TASK REQUEST 

;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (IDENT) 
7;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (TASK) 
;CLEAR STOP BIT (CONDITIONALIZED ON SHUFFLING) 


CONTROL BLOCK TYPE INDEPENDENT OFFSET DEFINITIONS 


~ASECT 


-LNK: .BLKW 
-ROQOT: .BLKB 
-EFN: .BLKB 
-TCB: .BLKW 
-TIM: .BLKW 


CLOCK QUEUE 


=C.TIM+4 

-AST: .BLKW 
~-SRC: .BLKW 
-DST: .BLKW 


CLOCK QUEUE 


DEFINITIONS 


=C.TIM+4 
-RSI: .BLKW 
-UIC: .BLKW 


CLOCK QUEUE 


=C.TIM+4 
. BLKW 
- BLKW 


;CLOCK QUEUE THREAD WORD 

REQUEST TYPE 

;EVENT FLAG NUMBER (MARK TIME ONLY) 

7TCB ADDR OR SYSTEM SUBROUTINE IDENTIFICATION 
;ABSOLUTE TIME WHEN REQUEST COMES DUE 


NO 


CONTROL BLOCK-MARK TIME DEPENDENT OFFSET DEFINITIONS 


;START OF DEPENDENT AREA 

;AST ADDRESS 

;FLAG MASK WORD FOR 'BIS' SOURCE 
;ADDRESS OF 'BIS' DESTINATION 


bb 


CONTROL BLOCK~PERIODIC RESCHEDULING DEPENDENT OFFSET 


;START OF DEPENDENT AREA 
2 ;RESCHEDULE INTERVAL IN CLOCK TICKS 
1 ;SCHEDULING UIC 


CONTROL BLOCK-SINGLE SHOT DEPENDENT OFFSET DEFINITIONS 


;START OF DEPENDENT AREA 
;TWO UNUSED WORDS 
;SCHEDULING UIC 


HN 
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CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET 
DEFINITIONS 


THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST: 


me Me MA Me MO TO Me MO HAR MO MO Me 


TYPE 6 = SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE 
AS AN IDENTIFIER. 
TYPE 8 = SINGLE SHOT INTERNAL SUBROUTINE WITH A TCB ADDRESS 
AS AN IDENTIFIER. 
~=C.TIM+4 ;START OF DEPENDENT AREA 
000012 C.SUB: .BLKW 1 ;SUBROUTINE ADDRESS 
000014 C.AR5: .BLKW ut ;RELOCATION BASE (FOR LOADABLE DRIVERS) 
000016 .- BLKW 1 ;ONE UNUSED WORD 
000020 C.LGTH=. ;LENGTH OF CLOCK QUEUE CONTROL BLOCK 
. PSECT 
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DCBDF$ 


DCBDF$ 


DEVICE CONTROL BLOCK 


THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT 
A DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS. THERE IS 
AT LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM. FOR EXAMPLE, 
IF THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE 
DCB WITH THE DEVICE NAME 'TT'. IF PART OF THE TELETYPES WERE 
INTERFACED VIA DL11-A'S AND THE REST VIA A DH11, THEN THERE 
WOULD BE TWO DCB'S. ONE FOR ALL DL11-A INTERFACED TELETYPES, 

AND ONE FOR ALL DH11 INTERFACED TELETYPES. 


me te Te NO TO Ne TSH Ne WH We We WE 


- ASECT 
- =0 

000000 D.LNK: .BLKW 1 ;LINK TO NEXT DCB 
000002 D.UCB: .BLKW 1 ;POINTER TO FIRST UNIT CONTROL BLOCK 
000004 D.NAM: .BLKW dl ;GENERIC DEVICE NAME 
000006 D.UNIT: .BLKB Hf ;LOWEST UNIT NUMBER COVERED BY THIS DCB 
000007 - BLKB 1 ;HIGHEST UNIT NUMBER COVERED BY THIS DCB 
000010 D.UCBL: .BLKW 1 ;LENGTH OF EACH UNIT CONTROL BLOCK IN BYTES 
000012 D.DSP: .BLKW 1 ;POINTER TO DRIVER DISPATCH TABLE 
000014 D.MSK: .BLKW ur ;LEGAL FUNCTION MASK . CODES 0-15. 
000016 - BLKW aL ;CONTROL FUNCTION MASK CODES 0-15. 
000020 - BLKW 1 s;NOP'ED FUNCTION MASK CODES 0-15. 
000022 - BLKW 1 7;ACP FUNCTION MASK CODES 0-15. 
000024 - BLKW 1 ;LEGAL FUNCTION MASK CODES 16.-31. 
000026 - BLKW af ;CONTROL FUNCTION MASK CODES 16.-31. 
000030 - BLKW 1 ;NOP'ED FUNCTION MASK CODES 16.-31. 
000032 - BLKW 1 ;ACP FUNCTION MASK CODES 16.-31. 
000034 D.PCB: .BLKW 1 ;LOADABLE DRIVER PCB ADDRESS 

- PSECT 


me "eG Ne 


DRIVER DISPATCH TABLE 


OFFSET DEFINITIONS 


D. VDEB=1 77776 ;DEALLOCATE INTERNAL BUFFERS (FD TTDRV) 
D. VINI=0 ;DEVICE INITIATOR 

D. VCAN=2 7CANCEL CURRENT I/O FUNCTION 

D. VOUT=4 ;DEVICE TIMEOUT 

D. VPWF=6 ; POWERFAIL RECOVERY 


000000 
000002 
000004 
000005 
000006 
000012 
000013 
000014 
000016 
000020 
000020 
000021 
000022 
000030 
000031 
000032 


000034 


=e Ne WO 
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-=0 

ESHLGH: 
ESHSBF: 
ESHSYS: 
ESHIDN: 
ESHSID: 
ESHCTX: 
ESHFLG: 
ESHENS: 
ESHERS: 
ESHENC: 
ESHTYC: 
ESHTYS: 
ESHTIM: 
ESHPTY: 


ESHURM: 


ESHLEN: 
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EPKDFS$ 

ERROR MESSAGE BLOCK DEFINITIONS 
.ASECT 

HEADER SUBPACKET 
+-----~-----~--~—--- - - - - - - - - + 
| SUBPACKET LENGTH IN BYTES | 
+--------------------- -- - - - - - - - - ee + 
| SUBPACKET FLAGS | 
+----------------------- +----------------------- + 
| FORMAT IDENTIFICATION | OPERATING SYSTEM CODE | 
4+----------------------- 4+----------------------- + 


| OPERATING SYSTEM IDENTIFICATION | 


$----------------------- $----------------------- + 
| FLAGS | CONTEXT CODE | 
$----------------------- $----------------------- + 
| ENTRY SEQUENCE | 
+----------------------------------------------- + 
| ERROR SEQUENCE j 
$on--------------------- +----------------------- + 
| ENTRY TYPE SUBCODE | ENTRY TYPE CODE | 
$---------- ----- $----------------------- + 
| TIME STAMP | 
| | 
| | 
$----------------------- $----------------------- + 
| RESERVED | PROCESSOR TYPE | 
$----------------------- 4$----------------------- + 
| PROCESSOR IDENTIFICATION (URM) | 
$------------------------- --- ---- --- - ----------- + 
- BLKW i ; SUBPACKET LENGTH IN BYTES 
- BLKW 1 3; SUBPACKET FLAGS 
- BLKB 1 ; OPERATING SYSTEM CODE 
- BLKB sl 3; FORMAT IDENTIFICATION 
- BLKB 4 ; OPERATING SYSTEM IDENTIFICATION 
- BLKB si 3; CONTEXT CODE 
- BLKB 1 ; FLAGS 
- BLKW bu ; ENTRY SEQUENCE NUMBER 
- BLKW 1 ; ERROR SEQUENCE NUMBER 

; ENTRY CODE 
- BLKB 1 ; ENTRY TYPE CODE 
-BLKB Zs ; ENTRY TYPE SUBCODE 
-BLKB- 6 ; TIME STAMP 
- BLKB 1 3; PROCESSOR TYPE 
- BLKB a ; RESERVED 
-BLKW a 3; PROCESSOR IDENTIFICATION (URM) 
- EVEN 

; LENGTH 


me SO tO 


=e =e we 


me 68 68 
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SUBPACKET FLAGS 


SM. ERR 
SM.HDR 
SM.TSK 
SM.DID 
SM.DOP 
SM. DAC 
SM.DAT 
SM.MBC 
SM.CMD 
SM.ZER 


me ™e MO Ne TO HO NE Ne Me NO 


CODES FOR FIELD ESHIDN 


EHSFOR 


FLAGS FOR THE 


ES.INI 
ES. DAT 
ES.LIM 
ES.LOG 


1 ; 


ERROR LOG 


OP NE 
me MO MO we 


FOR ESHSBF 


ERROR PACKET 

HEADER SUBPACKET 

TASK SUBPACKET 

DEVICE IDENTIFICATION SUBPACKET 
DEVICE OPERATION SUBPACKET 
DEVICE ACTIVITY SUBPACKET 

DATA SUBPACKET 

22-BIT MASSBUS CONTROLLER PRESENT 
ERROR LOG COMMAND PACKET 

ZERO I/O COUNTS 


CURRENT PACKET FORMAT 


FLAGS BYTE (SERFLA) IN THE EXEC 


ERROR LOG INITIALIZED 
ERROR LOG RECEIVING DATA PACKETS 
ERROR LIMITING ENABLED 
ERROR LOGGING ENABLED 


TYPE AND SUBTYPE CODES FOR FIELDS ESHTYC AND ESHTYS 


SYMBOLS 
SYMBOLS 


ESCCMD 
ESSSTA 
ESSSWI 
ESSAPP 
ESSBAC 
ESSSHO 
ESSCHL 


ESCERR 
ESS DVH 
ESSDVS 
ESSTMO 
ESS UNS 


ESCDVI 
ESS DVI 


ESCDCI 
ESSMOU 
ESS DMO 
ESSRES 
ESSRCT 


ESCCPU 
ESSMEM 
ESSINT 


ESCSYS 
ESS PWR 
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WITH NAMES ESCXXX ARE TYPE CODES FOR FIELD ESHTYC, 
WITH NAMES ESSXXX ARE SUBTYPE CODES FOR FIELD ESHTYS. 


ERROR LOG CONTROL 
ERROR LOG STATUS CHANGE 
SWITCH LOGGING FILES 
APPEND FILE 
DECLARE BACKUP FILE 
SHOW 
CHANGE LIMITS 


DEVICE ERRORS 
DEVICE HARD ERROR 
DEVICE SOFT ERROR 
DEVICE INTERRUPT TIMEOUT 
DEVICE UNSOLICITED INTERRUPT 


DEVICE INFORMATION 
DEVICE INFORMATION MESSAGE 


DEVICE CONTROL INFORMATION 
DEVICE MOUNT 
DEVICE DISMOUNT 
DEVICE COUNT RESET 
BLOCK REPLACEMENT 


CPU DETECTED ERRORS 
MEMORY ERROR 
UNEXPECTED INTERRUPT 


SYSTEM CONTROL INFORMATION 
POWER RECOVERY 


000000 
000002 
000006 
000010 
000012 
000013 


000014 


CODES 


me Se Ne 


CODES 
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- =0 

ESTLGH: 
ESTTSK: 
ESTUIC: 
ESTTIDs 
ESTTIUs 
ESTFLG: 


EST LEN: 


FLAGS 


=e Se MS 
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ESCCTL 
ESSTIM 
ESSCRS 
ESS LOA 
ESSUNL 
E SSHRC 
ESSMES 


ESCSDE 
ESSABO 


OW PWN EF ~) 
=e TO SO MO ue we NO 


10 ; 
1 


CONTROL INFORMATION 
TIME CHANGE 
SYSTEM CRASH 
DEVICE DRIVER LOAD 
DEVICE DRIVER UNLOAD 
RECONFIGURATION STATUS CHANGE 
MESSAGE 


SOFTWARE DETECTED EVENTS 
TASK ABORT 


FOR CONTEXT CODE ENTRY ESHCTX 


wy Ase 


TASK SUBPACKET 


EHSNOR = 1 ; NORMAL ENTRY 

EHSSTA = 2 ; START ENTRY 

EHSCRS = 3; CRASH ENTRY 

FOR FLAGS ENTRY ESHFLG 

EHSVIR = 1 ; ADDRESSES ARE VIRTUAL 

EHSEXT = 2 ; ADDRESSES ARE EXTENDED 

EHSCOU = 4 ; ERROR COUNTS SUPPLIED 

PER ea ee eS SES SSS ee ee See + 
| TASK SUBPACKET LENGTH l 
$------------- +--+ 5-5 5-5 5-55 = - == = == + 


$-----------------------~------- -- - -- - - - = - = - = == + 
| TASK UIC | 
4$----------------------- -- -- -- --- - + - - - - - = + 
| TASK TI: DEVICE NAME | 
$----------------------- $----------------------- + 
| FLAGS {| TASK TI: UNIT NUMBER | 
$----------------------- +----------------------- + 
BLEW 1 ; TASK SUBPACKET LENGTH 

BLEW 2 ; TASK NAME IN RAD5O 

-BLKEW 1 ; TASK UIC 

.BLKB 2 ; TASK TI: DEVICE NAME 

-BLKB 1 ; TASK TI: UNIT 

-BLKB 1 ; FLAGS 

. EVEN 

FOR ENTRY ESTFLG 

ETSPRV = 1 ; TASK IS PRIVILEGED 

ETSPRI = 2 ; TERMINAL IS PRIVILEGED 


000000 
000002 
000004 
000005 
000006 
000007 


ST ik en eT ek ee ee, | i? | eT er) | eT | et eT rT rT Yh ) YT | eS | i ee ee |) |) en TY 


- =0 

ESILGH: 
ESILDV: 
ESILUN: 
ESI PCO: 
ESI PUN: 
ESIPSU: 


ESI PDV: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


DEVICE IDENTIFICATION SUBPACKET 


+------------------~------------------ - - ------ = + 
| DEVICE IDENTIFICATION SUBPACKET LENGTH | 
+--------------------- -- ------------------------ + 
| DEVICE MNEMONIC NAME | 
+----------------------- +----------------------- + 
| CONTROLLER NUMBER | DEVICE UNIT NUMBER | 
4+----------------------- 4+------------~----------- + 
| PHYSICAL SUBUNIT # | PHYSICAL UNIT # | 
4+----------------------- +----------------------- + 
| PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
4+----------------------- 4+----------------------- + 
|] RESERVED | FLAGS | 
4---------- - -- - - 4+--------~--------------- + 
| VOLUME NAME OF MOUNTED VOLUME 
| | 
| | 
| | 
| | 
| | 
4+----------------- -- -- - - - - - = - - = + 
| PACK IDENTIFICATION | 
] | 
4+---------------------------- -- - -- ---- - - -- - = + 
| DEVICE TYPE CLASS | 
4+------~---------- - - = - - - - = + 
|} DEVICE TYPE | 
| | 
4+--------------- - - - = - - - eee + 
| I/O OPERATION COUNT LONGWORD | 
| | 
$----------------------- 4+----------------------- + 
| HARD ERROR COUNT | SOFT ERROR COUNT 
4+----------------------- 4+---~----------—--------- + 
| BLOCKS TRANSFERRED COUNT (RSX-11M-PLUS ONLY) | 
| | 
4+---------------------- +--+ - + 
| CYLINDERS CROSSED COUNT (RSX-11M-PLUS ONLY) | 
| 
4+---------------------- - - - - - - - - - - - - - - - - - - === + 
. BLKW 1 ; DEVICE IDENTIFICATION SUBPACKET LENGTH 
. BLKW 1 ; DEVICE MNEMONIC NAME 

. BLKB ] ; DEVICE UNIT NUMBER 

. BLKB at ; CONTROLLER NUMBER 

. BLKB 1 ; PHYSICAL UNIT NUMBER 

. BLKB 1 : PHYSICAL SUBUNIT NUMBER 


~IF DF RSSMPL 


. BLKW 1 PHYSICAL DEVICE MNEMONIC 


=e 


~ENDC ; RSSMPL 


000010 
000011 
000012 
000026 
000032 
000032 
000034 
000040 
000044 
000045 


000046 


000000 
000002 
000006 
000010 
000012 
000013 
000014 
000016 
000017 


ESIFLG: 


ESIVOL: 
ESI PAK: 
ESIDEV: 
ESIDCL: 
ESIDTY: 
ESIOPR: 
ESIERS: 
ESIERH: 


ESILEN: 


FLAGS 


we MO Me 


me TO NO ME MO NO NO Ne NH Me NH NO NO We Ne NO TA NO WO WH WO ME GO Me Ne NO Ne 


-=0 

ESOLGN: 
ESOTSK: 
ESOUIC: 
ESOTID: 


ESOFNC: 
ESOFLG: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


.- BLKB 
- BLKB 
.- BLKB 
- BLKB 


- BLKW 
- BLKW 
~BLKW 
.- BLKB 
- BLKB 


~IF DF RSSMPL 


- BLKW 
~BLKW 


~ENDC ; 


- EVEN 


FOR FIELD ESIFLG 


EISSUB 


2 
2 


RSSMPL 


me Me MO Me we Ne MO ND NO Me 


=o 6 ™€O 


=e 


e 
’ 


FLAGS 

RESERVED 

VOLUME NAME 

PACK IDENTIFICATION 

DEVICE TYPE 

DEVICE TYPE CLASS 

DEVICE TYPE 

I/O OPERATION COUNT LONGWORD 
SOFT ERROR COUNT 

HARD ERROR COUNT 


BLOCKS TRANSFERRED COUNT 


CYLINDERS CROSSED COUNT 


SUBPACKET LENGTH 


SUBCONTROLLER DEVICE 


DEVICE OPERATION SUBPACKET 


4+-------------—---------------- - - -- - - - - ------- + 
| TASK UIC | 
4+----------------------- - - - -- - - - - - = + - - = + 
| TASK TI: LOGICAL DEVICE MNEMONIC | 
+-~----------~----------- 4+----------------------- + 
| RESERVED | TASK TI: DEVICE UNIT | 
+-------------—---------- 4+----------------------- + 
| I/O FUNCTION CODE | 
4+----------------------- t----------------------- + 
| RESERVED | OPERATION FLAGS | 


$—---------------------- $----------------------- + 
| TRANSFER OPERATION ADDRESS | 


$----------------------- ------------------------ + 
| TRANSFER OPERATION BYTE COUNT l 
fo ooo - +--+ - 5 == ++ + 
| CURRENT OPERATION RETRY COUNT | 
$o--------------- +--+ +--+ 5 - +--+ + 
.BLKW 1 ; SUBPACKET LENGTH 

.BLKW 2 ; TASK NAME IN RAD50 

-BLKW 1 ; TASK UIC 

.BLKB 2 ; TASK TI: LOGICAL DEVICE MNEMONIC 
-BLKB 1 ; TASK TI: LOGICAL DEVICE UNIT 
.BLKB 1 ; RESERVED 

.BLKEW 1 ; I/O FUNCTION CODE 

-BLKB 1 ; OPERATION FLAGS 

-BLKB 1 ; RESERVED 


000020 
000024 
000026 


000030 


000000 


ESOADD: 
ESOSIZ: 
ESORTY: 


ESOLEN: 


FLAGS 


me ™O Me 


SALGH: 


me %™O MS BO MO Te Ne Wo We Ne We Me Ne We WH NH We WH We WO We We We WH We WO We Ne eg Be WE 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- BLKW 
- BLKW 
- BLKW 
- EVEN 


NS) 


FOR FIELD 


EOSTRA 
EOSDMA 
EOSEXT 
EOSPIP 


ESOFLG 


OPN EH 


I/O ACTIVITY SUBPACKET 


me “Me tO 


me 


me 


me MO Me 


TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 
CURRENT OPERATION RETRY COUNT 


DEVICE OPERATION SUBPACKET LENGTH 


TRANSFER OPERATION 

DMA DEVICE 

EXTENDED ADDRESSING DEVICE 
DEVICE IS POSITIONING 


$--~---------------------- --- --- - +--+ -- = -------- + 
|] I/O ACTIVITY SUBPACKET LENGTH | 
$---------------------- -- ~~ ---- - - +--+ +--+ -- - +--+ + 
- BLKW ii ; SUBPACKET LENGTH 


I/O ACTIVITY SUBPACKET ENTRY 


$---------------------- ++ --- -- 5 + + - - - === + 
| LOGICAL DEVICE NAME MNEMONIC | 
$----------------------- $-—---------------------- + 
| CONTROLLER NUMBER | LOGICAL DEVICE UNIT | 
$o---------------- += -- $--------- + --- === + 
| PHYSICAL SUBUNIT # | PHYSICAL UNIT NUMBER | 
$----------------------- $----------------------- + 
] PHYSICAL DEVICE MNEMONIC (RSX-11M-PLUS ONLY) | 
$----------------------- fone + 
| TASK TI: LOGICAL UNIT | DEVICE FLAGS | 
fo ------- = - $—----------------------- + 


| REQUESTING TASK NAME IN RADSO | 


pone 5 5 - + 5 - - - - - -- -- - --- === + 
] REQUESTING TASK UIC | 
$o--------- +--+ + e+ - - - 5 - - - - - -  -- - --- == - + 
| TASK TI: LOGICAL DEVICE NAME | 
$--------------+ +--+ +++ -- ---- -- - == --- -- ---- + + 
| I/O FUNCTION CODE | 
$--~--------------------- $----------------------- + 
| RESERVED | FLAGS | 
+--~-------------------- $o---------------------- + 


000000 
000002 
000003 
000004 
000005 


000006 
000007 
000010 
000014 
000016 
000020 
000022 
000023 
000024 
000030 


000032 


-=0 

ESALDV: 
ESALUN: 
ESAPCO: 
ESAPUN: 
ESAPSU: 


ESAPDV: 


ESADFG: 
ESATIU: 
ESATSK: 
ESAUIC: 
ESATID: 
ESAFNC: 
ESAFLG: 


ESAADD: 
ESASIZ: 


ESALEN: 


FLAGS 


ue ™O we 


FLAGS 


me MO Me 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- BLKW 
- BLKB 
- BLKB 
- BLKB 
-BLKB 


a 


me Se Se we NO 


~IF DF RSSMPL 


. BLKW 


. ENDC 


- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLEW 
-BLKwW 
- EVEN 


1 


™~e 


ve) 
in 
yn 
= 
a) 
0 


aN ee eee ee 


FOR FIELD 


EASS UB 


=e “Se ™O8 MO NO Me ME MO Ne Ne 


=e 


ESADFG 


M23 


FOR FIELD ESAFLG 


EASTRA 
EASDMA 
EASEXT 
EASPIP 


«PS ECT 


OF NFR 
me Me me me 


LOGICAL DEVICE NAME MNEMONIC 
LOGICAL DEVICE UNIT 
CONTROLLER NUMBER 

PHYSICAL UNIT NUMBER 
PHYSICAL SUBUNIT NUMBER 


PHYSICAL DEVICE MNEMONIC 


DEVICE FLAGS 

TASK TI: LOGICAL UNIT 
REQUESTING TASK NAME IN RAD50 
REQUESTING TASK UIC 

TASK TI: LOGICAL DEVICE NAME 
I/O FUNCTION CODE 

FLAGS 

RESERVED 

TRANSFER OPERATION ADDRESS 
TRANSFER OPERATION BYTE COUNT 


SUBPACKET ENTRY LENGTH 


SUBCONTROLLER DEVICE 


TRANSFER OPERATION 

DMA DEVICE 

DEVICE HAS EXTENDED ADDRESSING 
DEVICE IS POSITIONING 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


F11DF$ ,,SYSDEF 
7 
: VOLUME CONTROL BLOCK 
. ASECT 
000000 V.TRCT: .BLKW 1 : TRANSACTION COUNT 
.IF DF RSS11M 
000002 V.TYPE: .BLKB 1 ; VOLUME TYPE DESCRIPTOR 
VT. SLl= 1 ; FILES-11 STRUCTURE LEVEL 1 
VT.ANS= 10 ; ANSI LABELED TAPE 
VT.UNL= 11 ; UNLABELED TAPE 
000003 V.VCHA: .BLKB 1 ; VOLUME CHARACTERISTICS 
vc. SLK= 1 ; CLEAR VOLUME VALID ON DISMOUNT 
VC.HLK= 2 ; UNLOAD THE VOLUME ON DISMOUNT 
vVC.DEA= 4 ; DEALLOCATE THE VOLUME ON DISMOUNT 
vc. PUB= 10 ; SET (CLEAR) US.PUB ON DISMOUNT 
000004 V.LABL: .BLKB 14 ; VOLUME LABEL (ASCIT) 
000020 V.PKSR: .BLKW 2 ; PACK SERIAL NUMBER FOR ERROR LOGGING 
000024 V.SLEN: ; LENGTH OF SHORT VCB 
.ENDC ;RS$$11M 
000024 V.IFWI: .BLKW 1 ; INDEX FILE WINDOW 
-IF DF RS$$11D 
V.STD: .BLKW 1 ; STD OF TASK CHARGED WITH NODE 
-ENDC ;R$$11D 
000026 V.FCB: .BLKW 2 ; FILE CONTROL BLOCK LIST HEAD 
000032 V.IBLB: .BLKB 1 ; INDEX BIT MAP 1ST LBN HIGH BYTE 
000033 V.IBSZ: .BLKB 1 ; INDEX BIT MAP SIZE IN BLOCKS 
000034 . BLKW 1 ; INDEX BITMAP 1ST LBN LOW BITS 
000036 V.FMAX: .BLKW a ; MAX NO. OF FILES ON VOLUME 
000040 V.WISZ: .BLKB 1 ; DEFAULT SIZE OF WINDOW IN RTRV PTRS 
; VALUE IS < 128. 
000041 vV.SBCL: .BLKB 1 ; STORAGE BIT MAP CLUSTER FACTOR 
000042 V.SBSZ: .BLKW 1 ; STORAGE BIT MAP SIZE IN BLOCKS 
000044 V.SBLB: .BLKB i, ; STORAGE BIT MAP 1ST LBN HIGH BYTE 
000045 V.FIEX: .BLKB ai ; DEFAULT FILE EXTEND SIZE 
000046 . BLKW 1 ; STORAGE BIT MAP 1ST LBN LOW BITS 
.IF DF RSS11M 
000050 V.VOWN: .BLKW 1 ; VOLUME OWNER'S UIC 
000052 V.VPRO: .BLKW 1 ; VOLUME PROTECTION 
.~ENDC ;RS$11M 
000054 V.FPRO: .BLKW 1 ; VOLUME DEFAULT FILE PROTECTION 
000056 V.FRBK: .BLKB Hi ; NUMBER OF FREE BLOCKS ON VOLUME HIGH BYTE 
000057 V.LRUC: .BLKB 1 ; COUNT OF AVAILABLE LRU SLOTS IN FCB LIST 
000060 . BLKW 1 ; NUMBER OF FREE BLOCKS ON VOLUME LOW BITS 
000062 vV.STS: .BLKB 1 ; VOLUME STATUS BYTE, CONTAINING THE FOLLOWING 
VS.IFW= 1 ; INDEX FILE IS WRITE ACCESSED 
VS.BMW= 2 ; STORAGE BITMAP FILE IS WRITE ACCESSED 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


FIRST FREE INDEX FILE BITMAP BLOCK 
POINTER TO VCB EXTENSION 


000063 V.FFNU: .BLKB i 
000064 V.EXT: .BLKW 1 


000066 V.LGTH: ; SIZE IN BYTES OF VCB 


MOUNT LIST ENTRY 
EACH ENTRY ALLOWS ACCESS TO A SPECIFIED USER FOR A NON-PUBLIC DEVICE 


TO ALLOW EXPANSION, ONLY THE ONLY TYPE CODE DEFINED IS "1" FOR 
DEVICE ACCESS BLOCKS 


me we NO ue MO Ne MO Ne 


~ASECT 

- =0 
000000 M.LNK: .BLKW 1 ; LINK WORD 
000002 M.TYPE: .BLKB 1 ; TYPE OF ENTRY 

MT.MLS= 1 ; MOUNTED VOLUME USER ACCESS LIST 
000003 M.ACC: .BLKB 1L ; NUMBER OF ACCESSES 
000004 M.DEV: .BLKW ni 7 DEVICE UCB 
000006 M.TI: - BLKW Z 7 ACCESSOR TI: UCB 


000010 M.LEN: LENGTH OF ENTRY 


me 


FILE CONTROL BLOCK 


re Ty 


~ ASECT 
-=0 


000000 F.LINK: .BLKW 1 FCB CHAIN POINTER 


~e 


-IF DF R$$11D 


F.FEXT: .~BLKW lL POINTER TO EXTENSION FCB 
F.STD: .BLKW A ; STD OF TASK CHARGED WITH NODE 


=e 


-ENDC ;R$$11D 


000002 F.FNUM: .BLKW 
000004 F.FSEQ: .BLKW 
000006 - BLKB 
000007 F.FSQN: .BLKB 


1 FILE NUMBER 
dl 
1 
1 
000010 F.FOWN: .BLKW 1 
A 
1 
1 
2 


FILE SEQUENCE NUMBER 

NOT USED 

FILE SEGMENT NUMBER 

FILE OWNER'S UIC 

FILE PROTECTION CODE 

USER CONTROLLED CHARACTERISTICS 
SYSTEM CONTROLLED CHARACTERISTICS 
FILE HEADER LOGICAL BLOCK NUMBER 


000012 F.FPRO: .BLKW 
000014 F.UCHA: .BLKB 
000015 F.SCHA: .BLKB 
000016 F.HDLB: .BLKW 


me MO Me MO MO MO NO MO tO 


BEGINNING OF STATISTICS BLOCK 

LBN OF VIRTUAL BLOCK 1 IF CONTIGUOUS 
0 IF NON CONTIGUOUS 

SIZE OF FILE IN BLOCKS 

NO. OF ACCESSES 

NO. OF LOCKS 


000022 F.LBN: .BLKW 2 


000026 F.SIZE: .BLKW 
000032 F.NACS: .BLKB 
000033 F.NLCK: .BLKB 


KE RD 


me me Se Me Ne NO 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


000012 S.STBK=.-F.LBN SIZE OF STATISTICS BLOCK 


000034 F.STAT: 

000034 F.NWAC: .BLKB fi 

000035 - BLKB 1 
FC.WAC= 100000 
FC.DIR= 40000 
FC.CEF= 20000 
FC.FCO= 10000 

000036 F.DREF: .BLKW 1 

000040 F.DRNM: .~.BLKW ue 


FCB STATUS WORD 

NUMBER OF WRITE ACCESSORS 

STATUS BITS FOR FCB CONSISTING OF 

SET IF FILE ACCESSED FOR WRITE 

SET IF FCB IS IN DIRECTORY LRU 

SET IF DIRECTORY EOF NEEDS UPDATING 

SET IF TRYING TO FORCE DIRECTORY CONTIG 
DIRECTORY EOF BLOCK NUMBER 

1ST WORD OF DIRECTORY NAME 


me He MO NO MO MO Ne Ne Ne 


-IF DF RSS$11M 


000042 F.FEXT: .~.BLKW al POINTER TO EXTENSION FCB 


=e 


~ENDC ;RSS11M 


000044 F.FVBN: .BLKW 2 
000050 F.LKL: .BLKW i 
000052 F.WIN: .BLKW a§ 


STARTING VBN OF THIS FILE SEGMENT 
POINTER TO LOCKED BLOCK LIST FOR FILE 
WINDOW BLOCK LIST FOR THIS FILE 


me ™Oe Ne 


000054 F.LGTH: 


~e 


SIZE IN BYTES OF FCB 


WINDOW 


me MO Me 


- ASECT 
- =0 
000000 W.ACT: NUMBER OF ACTIVE MAPPING POINTERS 
WHEN NO SECONDARY POOL 
BLOCK SIZE OF SECONDARY POOL SEGMENT 
WHEN SECONDARY POOL 
LOW BYTE = # OF MAP ENTRIES ACTIVE 
HIGH BYTE CONSISTS OF CONTROL BITS 
READ VIRTUAL BLOCK ALLOWED IF SET 
WRITE VIRTUAL BLOCK ALLOWED IF SET 
EXTEND ALLOWED IF SET 
SET IF LOCKED AGAINST SHARED ACCESS 
SET IF DEACCESS LOCK ENABLED 


000000 W.BLKS: 
000000 W.CTL: .BLKW 1 


WI.RDV= 400 

WI.WRV= 1000 
WI. EXT= 2000 
WI.LCK= 4000 
WI.DLK= 10000 


me "Oe MO MO MO me Ne MO Me WO MO 


-IF DF RSS$11M 


WI.PND= 20000 WINDOW TURN PENDING BIT 


=e 


~ENDC ;RSS$11M 


WI.EXL= 40000 
WI.WCK= 100000 


SET IF MANUAL UNLOCK DESIRED 
DATA CHECK ALL WRITES TO FILE 


«ee 


=e 


~IF NDF RS$S$11M IF NOT RSX-11 


~e 


W.FCB: .BLKW 
W.STD: .BLKW 
W.VBN: .BLKB 
W.WISZ: .BLKB 
- BLKW 
W.LKL: .BLKW 
W.WIN: .BLKW 
W.RTRV: 


FILE CONTROL BLOCK ADDRESS 

STD OF TASK CHARGED WITH WIDOW NODE 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

POINTER TO LiST OF USERS LOCKED BLOCKS 
WINDOW BLOCK LIST LINK WORD 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


a 


we “Oe ME MO NO MO MO NO 


000002 
000003 
000004 
000006 
000010 


000012 
000013 
000013 
000014 
000016 


000000 
000002 


W.IO0C: 


W.FCB: 
W.LKL: 
W.WIN: 


me Me te MO Ne 


W.VBN: 
W.MAP: 


W.WISZ: 


W.RTRV: 


Bl we Ne Ne Ne te Ne we 


MAP: 


ee ~e Ne Oe Ne MO MO 


W.USE: 
W. VBN: 


W.WISZ: 


W.RTRV: 


; LOCKED BLOCK LIST NODE 


° 
‘ 


-=0 
L.LNK: 
L.WI1: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


<LEF 


- BLKB 
- BLKB 
- BLKW 
. BLKW 
. BLKW 


~IF NB 


et 


SYS DEF 


-IF NDF PSSWND 


me *e BO MO NO 


e 
’ 


IF RSX-11 


COUNT OF I/O THROUGH THIS WINDOW 
RESERVED 

FILE CONTROL BLOCK ADDRESS 

POINTER TO LIST OF USERS LOCKED BLOCKS 
WINDOW BLOCK LIST LINK WORD 


IF SYSDEF SPECIFIED IN CALL 


IF SECONDARY POOL WINDOWS NOT ALLOWED 


NON-SECONDARY POOL WINDOW BLOCK 


IF SECONDARY POOL WINDOWS ARE NOT ENABLED, THE WINDOW BLOCK 
CONTAINS THE CONTROL INFORMATION AND RETRIEVAL POINTERS. 


- BLKB 


- BLKB 
- BLKW 


-IFF 


1 


be 
1 


me ™e MO Me NO 


HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 

DEFINE LABEL WITH ODD ADDR TO CATCH BAD REFS 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


IF WINDOWS IN SECONDARY POOL 


SECONDARY POOL WINDOW CONTROL AND MAPPING BLOCK 


IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, LUTN2 POINTS 
TO A CONTROL BLOCK IN SYSTEM POOL WHICH CONTAINS THE 
FOLLOWING CONTROL FIELDS AND THE MAPPING INFORMATION 

FOR THE SECONDARY POOL WINDOW. 


- BLKW 


1 


SECONDARY POOL WINDOW 


. 
s 


ADDR TO THE MAPPING PTRS IN SECONDARY POOL 


IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, THE RETRIEVAL 
POINTERS ARE MAINTAINED IN SECONDARY POOL IN THE FOLLOWING 


FORMAT 


ASSUME 
- BLKB 
- BLKB 
- BLKB 
- BLKB 
- BLKW 


« ENDC 
. ENDC 


- ENDC 


. ASECT 


- BLKW 
. BLKW 


; PSSWND 
:SYS DEF 


7;RSS11M 


1 


~e Me Me Me Me NO 


=e 


NUMBER OF ACTIVE MAPPING POINTERS 

STATUS OF BLOCK 

HIGH BYTE OF 1ST VBN MAPPED BY WINDOW 
SIZE IN RTRV PTRS OF WINDOW (7 BITS) 

LOW ORDER WORD OF 1ST VBN MAPPED 

OFFSET TO 1ST RETRIEVAL POINTER IN WINDOW 


END SECONDARY POOL WINDOW CONDITIONAL 
END SYSDEF CONDITIONAL 


END RSX-11M CONDITIONAL 


LINK TO NEXT NODE IN LIST 
POINTER TO WINDOW FOR FIRST ENTRY 


000004 
000005 
000006 


000010 


L. LKSZ: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


-IF DF 


- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 


~ TIFF 

- BLKB 
- BLKB 
- BLKW 


- ENDC 


- PSECT 


RS$$11D 


ee ONO 


1 
1 
ui 


;RSS11D 


~e te NA MO NO 


me "ee Ne 


POINTER TO STD OF TASK NODE CHARGED TO 
STARTING VBN OF FIRST ENTRY 

STARTING VBN OF SECOND ENTRY 

COUNT FOR FIRST ENTRY 

COUNT FOR SECOND ENTRY 


HIGH ORDER VBN BYTE 
COUNT FOR ENTRY 
LOW ORDER VBN 


000000 
000002 
000004 
0000106 
000012 
000014 
000016 
000020 
000022 
000024 
000026 
000030 
000032 
000034 
000036 
000040 
000042 
000044 
000046 
000050 
000052 
000054 
000056 
000060 
000061 
000062 
000064 
000065 
000066 
000072 
000074 
000076 


=e te Ne 


-=0 
H.CSP: 
H.HDLN: 
H. EFLM: 
H.CUIC: 
H.DUIC: 
H.IPS: 
H.IPC: 
H. ISP: 
H.ODVA: 
H.ODVL: 
H.TKVA: 
H.TKVL: 
H. PFVA: 
H.FPVA: 
H. RCVA: 
H.EFSV: 
H.FPSA: 
H.WND: 
H. DSW: 
H.FCS: 
H.FORT: 
H.OVLY: 
H. VEXT: 
H.SPRI: 
H.NML: 
H.RRVA: 
H. X25: 


H.GARD: 
H.NLUN: 
H. LUN: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


HDRDFS 


~ ASECT 


. BLKW 
.- BLKW 
-BLKW 
. BLKW 
- BLKW 
.- BLKW 
. BLKW 
. BLKW 
. BLKW 
. BLKW 
- BLKW 
. BLKW 
. BLKW 
. BLKW 
. BLKW 
-BLKW 
. BLKW 
. BLKW 
. BLKW 
. BLKW 
- BLKW 
. BLKW 
-BLKW 
. BLKB 
. BLKB 
. BLKW 
. BLKB 
.- BLKB 
. BLKW 
. BLKW 
. BLKW 
- BLKW 


NPP OPE ERP EEE EP PEEP PRP HP EPP PP RP RPE EO ee 


HDRDFS$ 


TASK HEADER OFFSET DEFINITIONS 


;CURRENT STACK POINTER 

;HEADER LENGTH IN BYTES 

;EVENT FLAG MASK WORD AND ADDRESS 
;CURRENT TASK UIC 

;DEFAULT TASK UIC 

; INITIAL PROCESSOR STATUS WORD (PS) 

; INITIAL PROGRAM COUNTER (PC) 

; INITIAL STACK POINTER (SP) 

;ODT SST VECTOR ADDRESS 

;ODT SST VECTOR LENGTH 

;TASK SST VECTOR ADDRESS 

;TASK SST VECTOR LENGTH 

;POWER FAIL AST CONTROL BLOCK ADDRESS 
;FLOATING POINT AST CONTROL BLOCK ADDRESS 
;RECIEVE AST CONTROL BLOCK ADDRESS 
;EVENT FLAG ADDRESS SAVE ADDRESS 
;POINTER TO FLOATING POINT/EAE SAVE AREA 
;POINTER TO NUMBER OF WINDOW BLOCKS 
;TASK DIRECTIVE STATUS WORD 

;FCS IMPURE POINTER 

;FORTRAN IMPURE POINTER 

;OVERLAY IMPURE POINTER 

;WORK AREA EXTENSION VECTOR POINTER 
;PRIORITY DIFFERENCE FOR SWAPPING 
;NETWORK MAILBOX LUN 

;RECEIVE BY REFERENCE AST CONTROL BLOCK ADDRESS 
;FOR USE BY X.25 SOFTWARE 

;FIVE RESERVED BYTES 


; 

;POINTER TO HEADER GUARD WORD 
;NUMBER OF LUN'S 

;START OF LOGICAL UNIT TABLE 


000000 
000002 
000004 
000006 
000010 
000012 
000014 
000015 
000016 


000020 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


LENGTH OF FLOATING POINT SAVE AREA 


Tite Se te 


»FPSL=25.%*2 


WINDOW BLOCK OFFSETS 


e me “Se we 


=0 
W.BPCB: .BLKW 1 ;PARTITION CONTROL BLOCK ADDRESS 
W.BLVR: .~BLKW A ;LOW VIRTUAL ADDRESS LIMIT 
W.BHVR: .BLKW 1 ;HIGH VIRTUAL ADDRESS LIMIT 
W.BATT: .~BLKW EE ;ADDRESS OF ATTACHMENT DESCRIPTOR 
W.BSIZ: .~BLKW 1 ;SIZE OF WINDOW IN 32W BLOCKS 
W.BOFF: .BLKW 1 ;PHYSICAL MEMORY OFFSET IN 32W BLOCKS 
W.BFPD: .BLKB 1 ;FIRST PDR ADDRESS 
W.BNPD: .BLKB 1 ;NUMBER OF PDR'S TO MAP 
W.BLPD: .~BLKW Ab ;CONTENTS OF LAST PDR 
W.BLGH: ;LENGTH OF WINDOW DESCRIPTOR 


- PSECT 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


HWDDFS$ 


~e we MO 


MPCSR=177746 
MPAR=1 72100 
PIRQ=177772 
PR O=0 
PR1=40 
PR4=200 
PR5=240 
PR6=300 
PR7=3 40 
PS=177776 
SWR=1 77570 
TPS=177564 


me MO §F 


-IF DF ESSEAE 
AC=177302 
MQ=177304 
SC=177310 


~ENDC ;ESSEAE 


me MO Me 


-IF DF MSSMGE 


KDSAR0=1 72 360 
KDS DR0=1 72 320 
KISARO=172 340 
KINARO=KISARO 
KISAR5=172 352 
KINAR5=KISAR5 
KISAR6=1 72354 
KINAR6=KISAR6 
KISAR7=1 72356 
KINAR7=KISAR7 
KISDRO0=1 72 300 
KISDR6=1 72314 
KISDR7=1 72316 
SISDRO=1 72200 
UDSARO0=177660 
UDS DRO=177620 
UISARO0=177640 
UISAR4=177650 
UISAR5=177652 
UISAR6=177654 
UISAR7=177656 
UISDRO=177600 


HARDWARE REGISTER ADDRESSES AND STATUS CODES 


HWDDF$ 


;ADDRESS OF PDP-11/70 MEMORY PARITY REGISTER 
;ADDRESS OF FIRST MEMORY PARITY REGISTER 
;PROGRAMMED INTERRUPT REQUEST REGISTER 


; PROC 
; PROC 
3; PROC 
7 PROC 


ESSOR 
ESSOR 
ESSOR 
ESSOR 


; PROCESSOR 


3; PROC 
; PROC 


ESSOR 
ESSOR 


PRIORITY 
PRIORITY 
PRIORITY 
PRIORITY 
PRIORITY 
PRIORITY 
STATUS WORD 


NNO ArH O 


;CONSOLE SWITCH AND DISPLAY REGISTER 
;CONSOLE TERMINAL PRINTER STATUS REGISTER 


EXTENDED ARITHMETIC ELEMENT REGISTERS 


; ACCUMULATOR 
;MULTIPLIER-QUOTIENT 
;SHIFT COUNT 


> KERN 


; KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
» KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
; KERNEL 
; SUPERVISOR 


;USER 
; USER 
;USER 
;USER 
;USER 
; USER 
;USER 
;USER 


EL 


PAR 
PDR 
PAR 
PAR 
PAR 
PAR 
PAR 
PDR 


HHHHHHOY 


HHHHHHHHHHH YY 
UG 0 
> > 
aw 
WAAINOANAATANAMNNOCDAOO 


MEMORY MANAGEMENT HARDWARE REGISTERS AND STATUS CODES 


DR 0 


OANDOBROODOOH 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


UISDR 4=177610 
UISDR5=177612 
UISDR6=177614 
UISDR7=177616 
UBM PR=1 70200 
CMODE=1 40000 
PMODE=30000 
SRO=177572 
SR3=172516 


-« ENDC 


;USER I PDR 4 
;USER I PDR 5 
;USER I PDR 6 
;USER I PDR 7 


;UNIBUS MAPPING REGISTER 0 
;CURRENT MODE FIELD OF PS WORD 
;PREVIOUS MODE FIELD OF PS WORD 
;SEGMENT STATUS REGISTER 0 
;SEGMENT STATUS REGISTER 3 


; 
; FEATURE SYMBOL DEFINITIONS 


Ul 

FE. EXT=1 
FE.MUP=2 

FE. EXV=4 

FE. DRV=10 
FE. PLA=20 
FE.CAL=40 
FE. PKT=100 
FE. EXP=200 
FE.LSI=400 
FE, OFF=1000 
FE. FDT=2000 
FE. X25=4000 
FE. DYM=10000 
FE.CEX=20000 
FE.MXT=40000 
FE.NLG=100000 


oe "0 %e 


F2.DAS=1 

F2. LIB=2 
F2.MP=4 

F2. EVT=10 
F2. ACN=20 
F2. SDW=40 
F2. POL=100 
F2.WND=200 
F2.DPR=400 

F 2. IRR=1000 
F2.GGF=2000 
F 2. RAS=4000 
F 2, AHR=10000 
F2.RBN=20000 
F2.SWP=40000 
F2.STP=100000 


7;22-BIT EXTENDED MEMORY SUPPORT 
;MULTI-USER PROTECTION SUPPORT 
;EXECUTIVE IS SUPPORTED TO 20K 

; LOADABLE DRIVER SUPPORT 

;PLAS SUPPORT 

;DYNAMIC CHECKPOINT SPACE ALLOCATION 
;PREALLOCATION OF I/O PACKETS 

; EXTEND TASK DIRECTIVE SUPPORTED 
;PROCESSOR IS AN LSI-11 

; PARENT OFFSPRING TASKING SUPPORTED 
;FULL DUPLEX TERMINAL DRIVER 

;X.25 COM EXECUTIVE LOADED (1=YES) 

; DYNAMIC MEMORY ALLOCATION SUPPORTED 
7;COM EXEC IS LOADED 

;MCR EXIT AFTER EACH COMMAND MODE 

; LOGINS DISABLED - MULTI-USER SUPPORT 


SECOND FEATURE MASK SYMBOL DEFINITIONS 


;KERNEL DATA SPACE (M-PLUS ONLY) 
;SUPERVISOR MODE LIBRARIES " 
;MULTIPROCESSING SUPPORT bd 
; EVENT TRACE SUPPORT ” 
;CPU ACCOUNTING " 
;SHADOW RECORDING " 
; SECONDARY POOLS ” 
;SECONDARY POOL FILE WINDOWS z 


;DIRECTIVE PARTITION SUPPORT 

; INSTALL, REQUEST AND REMOVE SUPPORT 
;GROUP GLOBAL EVENT FLAG SUPPORT 
;RECEIVE/SEND DATA PACKET SUPPORT 
;ALT. HEADER REFRESH AREAS SUPPORTED 
;ROUND ROBIN SCHEDULING SUPPORT 

; EXECUTIVE LEVEL DISK SWAPPING SUPPORT 
;EVENT FLAG MASK IS IN THE TCB (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


; 
; THIRD FEATURE MASK SYMBOL DEFINITIONS 


F3.CRA=1 
F3.NWK=2 

F3. EIS=4 
F3.STM=10 
F3.UDS=20 
F3. PRO=40 
F3. XHR=100 
F3.AST=200 
F3.115=400 
F3.CLI=1000 
F3.TCM=2000 
F3.PMN=4000 
F3.WAT=10000 
F3.RLK=20000 


e =e ~e 


HF. UBM=1 
HF. EIS=2 
HF.CIS=200 


HF. FPP=100000 


HARDWARE FEATURE MASK 


;SPONTANEOUS CRASH (1=YES) 
;SYSTEM HAS NETWORK SUPPORT 

;SYSTEM REQUIRES THE EXTENDED INST. SET 
;SYSTEM HAS SET SYSTEM TIME DIRECTIVE 
;USER DATA SPACE (M-PLUS ONLY) 

;PROTO TCBS OUT OF POOL " 

; EXTERNAL HEADER SUPPORT "“ 

;SYSTEM HAS AST SUPPORT 

;SYSTEM IS RSX-11S 

;SYSTEM HAS MULTIPLE CLI SUPPORT 

; TERMINAL COMMON (M-PLUS ONLY) 

;POOL MONITORING SUPPORT 

;WATCHDOG TIMER SUPPORT 

; 'RMS' RECORD LOCKING SUPPORT 


SYMBOL DEFINITIONS 


;SYSTEM HAS A UNIBUS MAP (1=YES) 
;SYSTEM HAS EXTENDED INSTRUCTION SET 
;SYSTEM HAS COMMERCIAL INSTRUCTION SET 
;SYSTEM SUPPORTS FLOATING POINT (1=NO) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


ITBDFS ,,SYSDEF 
7 
; INTERRUPT TRANSFER BLOCK (ITB) OFFSET DEFINITIONS 
.IF DF ASSTRP 
~-MCALL PKTDFS 
PKTDFS ; DEFINE AST BLOCK OFFSETS 
~ENDC ;ASSTRP 
.ASECT 
000000 X.LNK: .BLKW 1 ; LINK WORD FOR ITB LIST STARTING IN TCB 
000002 xX.JSR: JSR R5,@#0 ; CALL SINTSC 
000006 X.PSW: .BLKB ; LOW BYTE OF PSW FOR ISR 
000007 .- BLKB 1 ; UNUSED 
000010 X.ISR: .BLKW al ; ISR ENTRY POINT (APR5 MAPPING) 
000012 X.FORK: ; FORK BLOCK 
000012 . BLKW ‘i ; THREAD WORD 
000014 . BLKW 1 ; FORK PC 
000016 . BLKW 1 ; SAVED R5 
000020 . BLKW 1 ; SAVED R4 
~IF DEF MSSMGE 
X.REL: .BLKW i ; RELOCATION BASE FOR APR5 
~ENDC ;MSSMGE 
X.DSI: .BLKW J. ; ADDRESS OF DIS.INT. ROUTINE 
X.TCB: .BLKW 1 ; TCB ADDRESS OF OWNING TASK 
~IF NB SYSDEF 
.IF DF ASSTRP 
. BLKW 1 ; A.DOSR FOR AST BLOCK 
X.AST: .BLKB A. PRM : AST BLOCK 
.ENDC ;ASSTRP 
X. VEC: .BLKW a ; VECTOR ADDRESS (IF AST SUPPORT, 
; THIS IS FIRST AND ONLY AST PARAMETER) 
X.VPC: .BLKW 1 ; SAVED VECTOR PC 
X. LEN: ; LENGTH IN BYTES OF ITB 
~ENDC ;SYSDEF 
.PSECT 


000000 
000002 
000004 
000005 
000006 
000010 


000012 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


LCBDF$ 


LCBDF$ 


LOGICAL ASSIGNMENT CONTROL BLOCK 


THE LOGICAL ASSIGNMENT CONTROL BLOCK (LCB) IS USED TO ASSOCIATE A 
LOGICAL NAME WITH A PHYSICAL DEVICE UNIT. LCB'S ARE LINKED TOGETHER 
TO FORM THE LOGICAL ASSIGNMENTS OF A SYSTEM. ASSIGNMENTS MAY BE ON 
A SYSTEM WIDE OR LOCAL (TERMINAL) BASIS. 


me we *e TH BO Te Me WO 


~ASECT 
-=0 
L.LNK: .BLKW il ;LINK TO NEXT LCB 
L.NAM: .BLKW 1 ;LOGICAL NAME OF DEVICE 
L.UNIT: .BLKB 1 ;LOGICAL UNIT NUMBER 
L.TYPE: .~BLKB 1 ;TYPE OF ENTRY (O=SYSTEM WIDE) 
L.UCB: .BLKW 1 ;TI UCB ADDRESS 
L.ASG: .BLKW Z ;ASSIGNMENT UCB ADDRESS 
L. LGTH=. -L. LNK ;LENGTH OF LCB 


- PSECT 


MTADF$ 


000000 
000002 
000003 
000004 
000020 
000022 
000024 
000026 
000030 
000032 
000033 
000034 
000036 
000040 
000042 
000043 
000044 
000046 
000054 
000055 


000056 
000060 
000062 
000070 
000072 
000074 
000100 
000104 
000110 
000111 
000112 


=e 
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~=0 
V.TCNT: 
V.TYPE: 
V.VCHA: 
V.LABL: 
V.NXT: 
V.MVL: 
V.UVL: 
V.ATL: 
V.UCB: 
V.RVOL: 
V.MOU: 
V.TCHR: 
V.SEQN: 
V.SECN: 
V.TPOS: 
V.PSTA: 
V.TIMO: 
V.STAT: 
V.TRTB: 
V.EFTV: 


LABEL 


me tO Me 


V.BLKL: 
V.RECL: 
V.FNAM: 
V.FTYP: 
V.FVER: 
V.CDAT: 
V.EDAT: 
V.BLKC: 
V.RTYP: 
V.FATT: 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


MTADFS$ 


VOLUME SET CONTROL BLOCK OFFSET DEFININTIONS 


- ASECT 


- BLKW 
- BLKB 
- BLKB 
- BLKB 
» BLKW 
- BLKW 
. BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
- BLKB 
- BLKB 


ANSI MAGTAPE SPECIFIC DATA STRUCTURES 


(VSCB) 


VOLUME SET AND PROCESS CONTROL SECTION 


7TRANSACTION COUNT 

; VOLUME TYPE DESCRIPTOR 
; VOLUME CHARACTERISTICS 
7;FILE SET ID (FIRST SIX BYTES) 

7;PTR TO NEXT VSCB NODE 

;PTR TO MOUNTED VOL LIST 

7PTR TO UNMOUNTED VOL LIST 

;ATL ADDR OF ACCESSING TASK TCB IN RSX11M 

ADDR OF CURRENT UCB OR PUD 

;CURRENT RELATIVE VOL # 

;MOUNT MODE BYTE 

;UINT CHAR. FOR ALL UNITS USED FOR VOL SET 
;CURRENT FILE SEQUENCE # 

;CURRENT FILE SECTION # 

POSITION OF TAPE IN TM'S TO NXT HDR1 

7;PROCESS STATUS BYTE 

;BLOCKED PROCESS TIMEOUT COUNTER 
;STATUS WORDS USED BY COMMAND EXECUTION MODULES 
;TRANSLATION CONTROL BYTE 
;FOR MAG TO RETURN IE.EOF, 


N 
° 


ee ee 


EOT, EOV 


DATA SECTION 


- BLKW 
- BLKW 
.- BLKW 
» BLKW 
. BLKW 
- BLKW 
- BLKW 
- BLKW 
- BLKB 
.- BLKB 
.- BLKB 


:;BLOCK LENGTH 

;RECORD LENGTH 

;FILE NAME 

;FILE TYPE 

;FILE VERSION # 

;CREATION DATE 

;EXPRIATION DATE 

;BLOCK COUNT FOR FILE SECTION 

;RECORD TYPE 

;FILE ATTRIBUTES FOR CARRIAGE CONTROL 
0. ;REMAINDER OF FILE ATTRIBUTES 


WREMNNRPEWH HE 


000150 
000160 
000162 
000163 
000164 
000205 


000000 


000000 


000002 
000004 
000006 


000010 
000011 
000012 
000014 


000016 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


NULL WINDOW SECTION 


we Oe we 


M.VIDP: 
M.UCB: - BLKW 


S.MVL=. 


V.WIND: .BLKW 4. ;NULL WINDOW 
V.MST2: .BLKW ui ;MAGTAPE STATUS BITS 
V.FABY: .BLKB al ;FILE ACCESSIBILITY BYTE (HDR1) 
.- BLKB a 7SPARE 
V.ANSN: .BLKB al ;ANSI 17 CHARACTER FILE NAME 
V.BOFF: .BLKB Ls ;BUFFER OFFSET 
V.DENS: .BLKB lg ;REQUESTED UNIT DENSITY 
‘V.DRAT: .BLKB Nips ;DEFAULT RECORD ATTRIBUTES 
V.DBLK: .~BLKW 1. ;DEFAULT BLOCK SIZE 
V.DREC: .~BLKW le ;DEFAULT RECORD SIZE 
S.VSCB=. ;SIZE OF VSCB 
- PSECT 
i 
; DEFINE OFFSETS INTO NULL WINDOW SECTION 
- ASECT 
-=0 
W.CTL: .BLKW Mi ;CONTROL WORD IN WINDOW 
V.WINC=V.WIND+.CTL ;CNTRL WORD IN NULL WINDOW 
;RELATIVE TO THE VSCB 
- PSECT 
; MOUNTED VOLUME LIST OFFSET DEFININTIONS (MVL) 
i 
-ASECT 
- =0 
-IF DF RS$11M 
M.NXT: .BLKW 1 7;PTR TO NXT MVL NODE (11M) 
-ENDC ;RS$11M 
M.UIC: .BLKW 1 ;OWNER UIC FROM RVOL #1 
M.CH: - BLKW 1 ;U.CH/U.VP (11D) 
M.PROT: .~BLKW a PROTECTION U.AR IN 11D 
-IF NDF RS$$11M 
- BLKW 2 ;ACP WORDS 11D 
M.NXT: .BLKW 1 ;PTR TO NEXT MVL NODE (11D) 
-ENDC ;RS$11M 
M.RVOL: .BLKB ;RELATIVE VOL # OF MOUNTED VOLUME 
M.STAT: .BLKB ; VOLUME STATUS 


7;VOLUME ID POINTER 
ADDR OF ASSOC UCB OR PUD 


7;SIZE OF MVL NODE 


me me we 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


UNMOUNTED VOLUME AND VOLUME 


LIST OFFSET DEFINITIONS (UVL) 


~ASECT 
- =0 

000000 L.NXT: .BLKW ui ;PTR TO NXT UVL NODE 
000002 L.VOLi: .BLKB 1 ;REL VOL # OF 1'ST VOL IN NODE 
000003 L.VOL2: .BLKB 1 ;REL VOL # OF 2'ND VOL IN NODE 
000004 L.VID1: .BLKB 6 ;VOL ID OF 1'ST VOL IN NODE 
000012 L.VID2: .BLKB 6 ;VOL ID OF 2'ND VOL IN NODE 
000020 S.UVL=. ;SIZE OF UVL NODE 

«PoECT 


; 
; SYSTEM DATA STRUCTURE CONTENT VALUES 


VSCB VALUES 


eo "=e Be MO ME 


V.MOU VALUES 
a 
VM.OLD = 200 ;OLD .FL300 VOLUME -- VM.BYP WILL ALSO BE SET 
VM.BYP = 100 ;BYPASS LABEL PROCESSING 
VM.ULB = 40 ; UNLABELED TAPE 
VWM.FSC = 20 ;OVERRIDE FILE SET ID CHECK 
VM.EXC = 10 ; OVERRIDE EXPRIATION DATE CHECK 
i 
; V.MST2 VALUES 
7 
V2.INI = 1 ;MAG WANTS US TO INITIALIZE NEXT OUTPUT 
V2.XH2 = 2 ;THIS FILE HAS NO HDR2, DON'T WRITE EOF2 
V2.XH3 = 4 ;THIS FILE HAS NO HDR3, DON'T WRITE EOF3 
V2.NH3 = 10 ;DON'T WRITE HDR3/EOX3 LABELS 
V2.O0AC = 20 ; OVERRIDE FILE/VOLUME ACCESSIBILITY 


- UNBLOCKED TRANSITION STATE 


VP. RM = 2 ;READ DATA MODE 

VP.WM = 4 ;WRITE DATA MODE 

VP.UCM = 6 ; UNLABELLED CREATE POSITIONING MODE 
VP.SM = 10 ; SEARCH MODE 

VP.MOU = 20 ;MOUNT MODE 

VP.RWD = 40 ;REWIND OR VOL VERIFICATION WAIT 
VP.VFY = VP. RWD 

VP.POS = 100 ;PROCESS IN POSITIONING MODE 


; (MULTI-SECTION FILE) 
BLOCKED STATE = -(UNBLOCKED TRANSITION STATE VALUES) 


PROCESS TIMED OUT BIT 0 = 1 


<j we se se we Ne 


P.TO=1 


e ™e ™e 


‘ 
WI.RDV 


WI.WRV 


WI. EXT 
WI.LCK 


e me me 


f 
MS.VER 
MS.RID 
MS.NMO 
MS.TMO 
MS. EXP 


MISC 


eo ™e me 


f 

MO. OVR 
MO.UIC 
MO. PRO 
MO. 160 


MVL VALUES IN 


Hou nw ue ou 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


400 

1000 
2000 
4000 


200 
1 

2 

4 
10 


NULL WINDOW CONTROL BIT DEFINITIONS 


ACCESSED FOR READ 

7; ACCESSED FOR WRITE 
; ACCESSED FOR EXTEND 
; LOCKED 


THE M.STAT FIELD 


;VOL ID NOT VERIFIED 

VOL ID TO BE READ NOT CHECKED 
;MOUNT MESSAGE NOT GIVEN YET 
;ONE TIMEOUT ALREADY EXPRIED 
;EXPIRATION DATE MESSAGE GIVEN 


BITS USED IN MOUNT (STORED IN V.STS) 


Mop te 


;OVER RIDE VOL NAME SWITCH 
;EXPLICIT UIC GIVEN 
;EXPLICIT PROTECTION GIVEN 
71600 BPI SPECIFIED 


PCBDF$ 


000000 
000002 
000003 
000004 
000010 
000012 


000014 
000016 
000016 


000020 
000022 
000024 
000026 
000026 
000030 


me TO Me 


- =0 

P.LNK: 
P.PRI: 
P.IOC: 
P.NAM: 
P.SUB: 
P.MAIN: 


P.HDR: 


P.REL: 
P.BLKS: 
P.SIZE: 


P.WAIT: 
P.SWSZ: 
P.BUSY: 
P.OWN: 
PSTICB: 
P.STAT: 


P.HDR: 


P, PRO: 
PVArTs 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


PCBDFS 


-ASECT 


.- BLKW 
- BLKB 
- BLKB 
- BLKW 
- BLKW 
.- BLKW 


-IF NB 


,, SYSDEF 


Be OHH Ee 


SYS DEF 


~IF NDF MSSMGE 


. ENDC 
~ lFTF 
- BLKW 
- BLKW 
. BLKW 
-BLKW 


.- BLKB 


- BLKW 
- BLKW 


-IFT 


:MSSMGE 


NH Re 


rH 


~-IF DF MSSMGE 


- BLKW 


- ENDC 


- BLKW 
- BLKW 


A 
:>MSSMGE 


al 
2 


~IF NDF PSSLAS 


PARTITION CONTROL BLOCK OFFSET DEFINITIONS 


;LINK TO NEXT PARTITION PCB 
;PRIORITY OF PARTITION 

;I1/O + I/O STATUS BLOCK COUNT 
;PARTITION NAME IN RAD50 
;POINTER TO NEXT SUBPARTITION 
;POINTER TO MAIN PARTITION 


;POINTER TO HEADER CONTROL BLOCK 


;STARTING PHYSICAL ADDRESS OF PARTITION 


SIZE OF PARTITION IN: 

UNMAPPED SYSTEMS - BYTES 

MAPPED SYSTEMS - 32 WORD BLOCKS 
;PARTITION WAIT QUEUE LISTHEAD (2 WORDS) 
;PARTITION SWAP SIZE (SYSTEM ONLY) 
;PARTITION BUSY FLAGS 


o w~e se OO 


;TCB ADDRESS OF OWNER TASK 
;PARTITION STATUS FLAGS 


;POINTER TO HEADER CONTROL BLOCK 


PROTECTION WORD [DEWR, DEWR, DEWR, DEWR] 
;ATTACHMENT DESCRIPTOR LISTHEAD 


;LENGTH OF PARTITION CONTROL BLOCK 


000000 
000002 
000003 
000004 
000006 
000010 
000011 
000012 


000014 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


- IFF 

P, LGTH=,. 
~ENDC ;PSSLAS 
- IFF 


«PSECT 


;LENGTH OF PARTITION CONTROL BLOCK 


i 
7 PARTITION STATUS WORD BIT DEFINITIONS 


PS. OUT=100000 
PS.CKP=40000 
PS.CKR=20000 
PS.CHK=10000 
PS.FXD=4000 
PS. PER=2000 
PS.LIO=1000 
PS.NSF=400 
PS.COM=200 
PS. PIC=100 
PS.SYS=40 
PS. DRV=20 
PS.DEL=10 


PS.APR=7 


ATTACHMENT DESCRIPTOR 


me ™e MO 


- ASECT 

- =0 

A.PCBL: .~.BLKW 
A.PRI: .BLKB 
A.IOC: .BLKB 
A.TCB: .BLKW 
A.TCBL: .~BLKW 
A.STAT: .~BLKB 
A.MPCT: .BLKB 
A.PCB: .BLKW 


PH HERE EEE 


A. LGTH=. 


‘ 
; ATTACHMENT DESCRIPTOR 
c 
- PSECT 
AS. DEL=10 
AS. EXT=4 
AS.WRT=2 
AS. RED=1 


-ENDC ;SYSDEF 


;PARTITION IS OUT OF MEMORY (1=YES) 

;PARTITION CHECKPOINT IN PROGRESS (1=YES) 
;PARTITION CHECKPOINT IS REQUESTED (1=YES) 
;PARTITION IS NOT CHECKPOINTABLE (1=YES) 
;PARTITION IS FIXED (1=YES) 

;PARITY ERROR IN PARTITION (1=YES) 

;MARKED BY SHUFFLER FOR LONG I/O (1=YES) 
;PARTITION IS NOT SHUFFLEABLE (1=YES) 

; LIBRARY OR COMMON BLOCK (1=YES) 

;POSITION INDEPENDENT LIBRARY OR COMMON (1=YES) 
;SYSTEM CONTROLLED PARTITION (1=YES) 

;DRIVER IS LOADED IN PARTITION (1=YES) 
;PARTITION SHOULD BE DELETED WHEN NOT ATTACHED 
; (L=YES) 

;STARTING APR NUMBER MASK 


OFFSETS 


;PCB ATTACHMENT QUEUE THREAD WORD 
:;PRIORITY OF ATTACHED TASK 

;1/O COUNT THROUGH THIS DESCRIPTOR 

;TCB ADDRESS OF ATTACHED TASK 

;TCB ATTACHMENT QUEUE THREAD WORD 

;STATUS BYTE 

;MAPPING COUNT OF TASK THRU THIS DESCRIPTOR 
;PCB ADDRESS OF ATTACHED TASK 


;LENGTH OF ATTACHMENT DESCRIPTOR 


STATUS BYTE BIT DEFINITIONS 


;TASK HAS DELETE ACCESS (1=YES) 
TASK HAS EXTEND ACCESS (1=YES) 
;TASK HAS WRITE ACCESS (1=YES) 
;TASK HAS READ ACCESS (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


PKTDFS$ 


177774 
177776 
000000 
000002 


000004 
000006 
000010 
000012 


PKTDFS 


ASYNCHRONOUS SYSTEM TRAP CONTROL BLOCK OFFSET DEFINITIONS 


SOME POSITIONAL DEPENDENCIES BETWEEN THE OCB AND THE AST CONTROL 
BLOCK ARE RELIED UPON IN THE ROUTINE SFINXT IN THE MODULE SYSXT. 


=™=e we OE Me TO ME 


. ASECT 
.=177774 
A.KSR5: .BLKW 
A.DOQSR: .BLKW 

. BLKW 
A.CBL: .BLKW 


;SUBROUTINE KISAR5 BIAS (A.CBL=0) 

;DEQUEUE SUBROUTINE ADDRESS (A.CBL=0) 

;AST QUEUE THREAD WORD 

;LENGTH OF CONTROL BLOCK IN BYTES 

;IF A.CBL = 0, THE AST CONTROL BLOCK IS 

7;TO BE DEALLOCATED BY THE DEQUEUE SUBROUTINE 
;POINTED TO BY A.DQSR MAPPED VIA APR 5 
7;VALUE A.KSR5. THIS IS CURRENTLY USED ONLY 
7;BY THE FULL DUPLEX TERMINAL DRIVER FOR 
;UNSOLICITED CHARACTER ASTS. 

7;IF THE LOW BYTE OF A.CBL = 0, AND THE 

HIGH BYTE IS NOT = 0, THE AST CONTROL BLOCK 
71S A SPECIFIABLE AST, WITH LENGTH, C.LGTH. 
;IF THE HIGH BYTE OF A.CBL = 0 AND THE LOW 
;BYTE > 0, THEN THE LOW BYTE IS THE LENGTH 
;OF THE AST CONTROL BLOCK. IF THE HIGH BYTE 
;OF A.CBL = 0 AND THE LOW BYTE IS NEGATIVE, 
;THIS IS A KERNEL AST. SEE BELOW FOR 

7A DESCRIPTION OF A.CBL FOR KERNEL ASTS. 
s;NUMBER OF BYTES TO ALLOCATE ON TASK STACK 
;AST TRAP ADDRESS 

;NUMBER OF AST PARAMETERS 

;FIRST AST PARAMETER 


HHP 


A.BYT: .BLKW 
A.AST: .BLKW 
A.NPR: .BLKW 
A.PRM: .BLKW 


a 


THE SPECIFIABLE AST CODES MUST NOT BE 0. 


e ™6 we 


q 

AS.FPA=1 ;CODE FOR FLOATING POINT AST 

AS. RCA=2 ;CODE FOR RECEIVE DATA AST 

AS. RRA=3 ;CODE FOR RECEIVE BY REFERENCE AST 

AS. PFA=4 ;CODE FOR POWERFAIL AST 

AS. REA=5 ;CODE FOR REQUESTED EXIT (ABORT) AST 
AS. CAA=6 ;CODE FOR COMMAND ARRIVAL AST FOR CLIS 


ABORTER SUBCODES FOR ABORT AST (AS.REA) TO BE RETURNED ON USER'S 
STACK 


e@ ™e “oe we 


e 

AB.NPV=1 ;ABORTER IS NONPRIVILEGED (1=YES) 

AB. TYP=2 ;ABORT FROM DIRECTIVE (0=YES) 
;ABORT FROM CLI COMMAND (1=YES) 


SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS 


KERNEL AST CONTROL BLOCK DEFINITIONS 

THE LOW BYTE OF A.CBL FOR A KERNEL AST HAS THE FOLLOWING FORMAT: 
BIT #200 ALWAYS EQUALS 1 
BIT #100 IS ZERO IF S$SGFIN MUST BE CALLED DURING AST PROCESSING 
THE REMAINING SIX BITS ARE USED AS THE KERNEL AST TYPE FIELD 


BECAUSE THERE ARE ONLY 6 BITS AVAILABLE TO THE KERNEL AST 
INDEX FIELD, ONLY (2**6)-1 KERNEL AST TYPES ARE POSSIBLE. 
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’ 

AK. BUF=200 ;BUFFERED I/O COMPLETION AST 

AK. OCB=201 ;OFFSPRING EXIT 

AK.GBI=202 ;GENERAL BUFFERED I/0 AST 

AK. TBT=203 ;TASK FORCED T-BIT TRAP AST 

AK. DIO=204 ;DELAYED I/O (M-PLUS COMPATIBLE) 


OFFSPRING CONTROL BLOCK DEFINITIONS 


SOME POSITIONAL DEPENDENCIES EXIST BETWEEN THE OCB AND THE AST 
CONTROL BLOCK IN ROUTINE SFINXT IN MODULE SYSXT 


e@ me Be Se Ne Ne NO 


000000 O.LNK: .BLKW at ;O0CB LINK WORD 

000002 O.MCRL: .BLKW uf ;ADDRESS OF MCR COMMAND LINE 
000004 O.PTCB: .BLKW 1 PARENT TCB ADDRESS 

000006 O.AST: .BLKW a ;EXIT AST ADDRESS 

000010 O.EFN: .BLKW 1 7;EXIT EVENT FLAG 

000012 O.ESB: .BLKW 1 7;EXIT STATUS BLOCK VIRTUAL ADDRESS 
000014 O.STAT: .BLKW 8. ;EXIT STATUS BUFFER 

000034 0O.LGTH=. ;LENGTH OF OCB 


; 

; I/O PACKET OFFSET DEFINITIONS 
~ASECT 

-=0 


000000 I.LNK: .BLKW 1 71/0 QUEUE THREAD WORD 

000002 I.PRI: .BLKB 1 ;REQUEST PRIORITY 

000003 I.EFN: .BLKB a ;EVENT FLAG NUMBER 

000004 I.TCB: .BLKW 1 ;TCB ADDRESS OF REQUESTOR 

000006 I.LN2: .BLKW Al ;POINTER TO SECOND LUN WORD 

000010 I.UCB: .BLKW 1 ;POINTER TO UNIT CONTROL BLOCK 

0000i2 I.FCN: .BLKW us 71/0 FUNCTION CODE 

000014 I.IOSB: .BLKW 1 ;VIRTUAL ADDRESS OF I/0 STATUS BLOCK 

000016 - BLKW a 7I/O STATUS BLOCK RELOCATON BIAS 

000020 - BLKW 1 71/0 STATUS BLOCK ADDRESS 

000022 I.AST: .BLKW i ;AST SERVICE ROUTINE ADDRESS 

000024 I.PRM: .BLKW 1 ;RESERVED FOR MAPPING PARAMETER #1 

000026 - BLKW 6 ; PARAMETERS 1 TO 6 

000042 - BLKW J ;USER MODE DIAGNOSTIC PARAMETER WORD 

000044 I.ATTL=. ;MINIMUM LENGTH OF I/O PACKET (USED BY 
;FILE SYSTEM TO CALCULATE MAXIMUM 
;NUMBER OF ATTRIBUTES) 

000044 I.LGTH=. ;LENGTH OF I/O REQUEST CONTROL BLOCK 
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i 
; GROUP GLOBAL EVENT FLAG CONTROL BLOCK OFFSETS 
i 


000000 G.LNK: .BLKW 1 ;LINK WORD 
000002 G.GRP: .BLKB 1 ;GROUP NUMBER 
000003 G.STAT: .BLKB n ;STATUS BYTE 
000004 G.CNT: .BLKW 1 ;ACCESS COUNT 
000006 G.EFLG: .BLKW 2 ;EVENT FLAGS 
000012 G.LGTH=. ;LENGTH OF GROUP GLOBAL CONTROL BLOCK 
; 
; STATUS BYTE DEFINITIONS 
; 
GS. DEL=1 ;GROUP MARKED FOR DELETE 


EXECUTIVE POOL MONITOR CONTROL FLAGS 
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SPOLST IS THE SYNCHRONIZATION WORD BETWEEN THE EXEC AND POOL MONITOR 
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f 

PC.HIH=1 HIGH POOL LIMIT CROSSED (1=YES) 

PC. LOW=2 7;LOW POOL LIMIT CROSSED (1=YES) 

PC. ALF=4 7POOL ALLOCATION FAILURE (1=YES) 
PC.NRM=PC.HIH*400 ;POOL TASK INHIBIT BIT FOR HIGH POOL 
PC. ALM=PC. LOW*400 POOL TASK INHIBIT BIT FOR LOW POOL 


S$POLFL IS THE POOL USAGE CONTROL WORD 


eo ™e Te 


’ 

PF.INS=40 ;REJECT NONPRIVILEGED INS/RUN/REM 

PF. LOG=100 ; LOGINS ARE DISABLED 

PF .REQ=200 ;STALL REQUEST OF NONPRIV. TASKS 

PF. ALL=177777 ;TAKE ALL POSSIBLE ACTIONS TO SAVE POOL 


; 
; CLI PARSER BLOCK (CPB) DEFINITIONS 
? 


000000 C.PTCB: .BLKW 
000002 C.PNAM: .BLKW 
000006 C.PSTS: .BLKW 
000010 C.PDPL: .BLKB ;LENGTH OF DEFAULT PROMPT 
000011 C.PCPL: .BLKB ;LENGTH OF CNTRL/C PROMPT 
000012 C.PRMT: ?;START OF ASCII PROMPT STRINGS 
;THE DEFAULT STRING IS CONCANTENATED 
;WITH THE “C STRING 


;ADDRESS OF CLI'S TCB 
;CLI NAME 
;STATUS MASK 


ee Oo 


000000 
000002 
000004 
000006 
000007 
000010 
000012 
000013 


000014 


000010 
000012 
000014 
000016 
000020 
000022 
000024 
000030 


000032 
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e 
’ 
e 
' 


CP.NUL=1 
CP.MSG=2 
CP. LGO=4 
CP.DSB=10 
CP. PRV=20 
CP.SGL=40 
CP.NIO=100 


CP. RST=200 


CP. EXT=400 


CODES 0 - 1 
CODES 128. 


e@ ~™e "ee Se SO Ne 


f 

CM. INE=1 
CM. IND=2 
CM.CEN=3 
CM.CDS=4 
CM. ELM=5 
CM. EXT=6 
CM. LKT=7 
CM.RMT=8. 
CM.MSG=9. 


A.REL: .BLKW 


A.DIS: .BLKW 
A.MAS: .BLKW 
A.NUM: .BLKB 
- BLKB 
A.LIN: .BLKW 
A.ACC: .BLKB 
A.STA: .BLKB 
A. LEN1=. 
- =A. LIN 
A.IMAP: .BLKW 
A.IBUF: .BLKW 
A.ILEN: .BLKW 
A.SMAP: .BLKW 
A.SBUF: .~BLKW 
A.SLEN: .BLKW 
A.IOS: .BLKW 
A.RES: .BLKW 
A. LEN2=, 


27. 
as 255. 


a 


PNR HP RE 


STATUS BIT DEFINITIONS 


ARE 


PASS EMPTY COMMAND LINES TO CLI 

;CLI DESIRES SYSTEM MESSAGES 

;CLI WANTS COMMANDS FROM LOGGED OFF TTYS 
;CLI IS DISABLED 

;USER MUST BE PRIV TO SET TTY TO THIS CLI 
;DON'T HANDLE CONTINUATIONS (M-PLUS ONLY) 
;MCR..., HEL, BYE DO NO I/O TO TTY 

;HEL, BYE ALSO DO NOT SET CLI ETC. 
;ABILITY TO SET TO THIS CLI IS RESTRICTED 
;TO THE CLI ITSELF 

;PASS TASK EXIT PROMPT REQUESTS TO CLI 


IDENTIFIER CODES FOR SYSTEM TO CLI MESSAGES, 


ARE RESERVED FOR USE BY DIGITAL, 


RESERVED FOR USE BY CUSTOMERS 


INITIALIZED ENABLED 
INITIALIZED DISABLED 
ENABLED 

DISABLED 

BEING ELIMINATED 

;CLI MUST EXIT IMMEDIATELY 
;NEW TERMINAL LINKED TO CLI 
;TERMINAL REMOVED FROM CLI 
yGENERAL MESSAGE TO CLI 


;CLI 
3;CLI 
;CLI 
7; CLI 
3; CLI 


7;ACD RELOCATION BIAS 

7ACD DISPATCH TABLE POINTER 
;ACD FUNCTION MASK 

7;ACD IDENTIFICATION NUMBER 
7RESERVED 

;ACD LINK WORD 

7;ACD ACCESS COUNT 

7;ACD STATUS BYTE 


;LENGTH OF PROTOTYPE ACB 


;FULL ACB OVERLAPS PROTOTYPE ACB 

;ACD INTERRUPT BUFFER RELOCATION BIAS 
;ACD INTERRUPT BUFFER ADDRESS 

;ACD INTERRUPT BUFFER LENGTH 

;ACD SYSTEM STATE BUFFER RELOCATION BIAS 
;ACD SYSTEM STATE BUFFER ADDRESS 

;ACD SYSTEM STATE BUFFER LENGTH 

;ACD I/O STATUS 

;RESERVED FOR USE BY THE ACD 


;LENGTH OF FULL ACB 


000000 
000002 
000004 
000006 
000010 
000012 
000014 
000016 
000020 
000022 
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DEFINE THE FLAG VALUES IN THE OFFSET U.AFLG 


UA. ACC=1 ;ACCEPT THIS CHARACTER 

UA. PRO=2 ;PROCESS THIS CHARACTER 

UA. ECH=4 ;ECHO THIS CHARACTER 

UA. TYP=10 7; FORCE THIS CHARACTER INTO TYPEAHEAD 
UA.SPE=20 ;THIS CHARACTER HAS A SPECIAL ECHO 

UA. PUT=40. ;PUT THIS CHARACTER IN THE INPUT BUFFER 
UA. CAL=100 ;CALL THE ACD BACK AFTER THE TRANSFER 
UA. COM=200 ;COMPLETE THE INPUT REQUEST 

UA. ALL=400 ;ALLOW PROCESSING OF THIS I/O REQUEST 
UA. TRA=1000 ; TRANSFER CHARS. WHEN I/O COMPLETES 


A 
A 
A 
A 
A 
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’ 
A 


-ACCE: .~BLKW 
-DEQU: .~BLKW 
-POWE: .~BLKW 
-INPU: .BLKW 
-OUTP: .~BLKW 
~CONN: .~BLKW 
-DISC: .~BLKW 
»RECE: .~BLKW 
- PROC: .BLKW 
-CALL: .~BLKW 


71/0 REQUEST ACCEPTANCE ENTRY POINT 

71/0 REQUEST DEQUEUE ENTRY POINT 

;POWER FAILURE ENTRY POINT 

; INPUT COMPLETION ENTRY POINT 

;OUTPUT COMPLETION ENTRY POINT 
;CONNECTION ENTRY POINT 

;DISCONNECTION ENTRY POINT 

; INPUT CHARACTER RECEPTION ENTRY POINT 

; INPUT CHARACTER PROCESSING ENTRY POINT 
;CALL ACD BACK AFTER TRANSFER ENTRY POINT 


ee 


DEFINE THE STATUS BITS IN A.STA OF THE PROTOTYPE ACB 


S.DEL=1 ;ACD IS MARKED FOR DELETE 


AS. DIS=2 ;ACD IS DISABLED 


- PSECT 


LITIIZ 
LIVIT3 
177774 
177776 
000000 
000004 
000005 
000006 
000007 
000010 
000011 
000012 
000014 
000016 
000020 
000020 
000022 
000024 
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SCBDF$ 


SCBDF$ ,,SYSDEF 


STATUS CONTROL BLOCK 


THE STATUS CONTROL BLOCK (SCB) DEFINES THE STATUS OF A DEVICE 
CONTROLLER. THERE IS ONE SCB FOR EACH CONTROLLER IN A SYSTEM. 
THE SCB IS POINTED TO BY UNIT CONTROL BLOCKS. TO EXPAND ON THE 
TELETYPE EXAMPLE ABOVE, EACH TELETYPE INTERFACED VIA A DL11-A 
WOULD HAVE A SCB SINCE EACH DL11-A IS AN INDEPENDENT INTERFACE 
UNIT. THE TELETYPES INTERFACED VIA THE DHil WOULD ALSO EACH HAVE 
AN SCB SINCE THE DH11 IS A SINGLE CONTROLLER BUT MULTIPLEXES MANY 
UNITS IN PARALLEL. 


me *™e Te ME MSH TO UG MO TO UO UME OME 


- ASECT 
-=177772 
S.RCNT: .BLKB 1 ;NUMBER OF REGISTERS TO COPY ON ERROR 
S.ROFF: .BLKB i ;OFFSET TO FIRST DEVICE REGISTER 
S.BMSV: .BLKW £ ;SAVED I/O ACTIVE BITMAP AND POINTER TO EMB 
S.BMSK: .BLKW 1 ;DEVICE I/O ACTIVE BIT MASK 
S.LHD: .BLKW 2 ;CONTROLLER I/O QUEUE LISTHEAD 
S.PRI: .BLKB 1 ;DEVICE PRIORITY 
S.VCT: .BLKB 1 ; INTERRUPT VECTOR ADDRESS /4 
S.CTM: .BLKB - ;CURRENT TIMEOUT COUNT 
S.ITM: .BLKB dL, ; INITIAL TIMEOUT COUNT 
S.CON: .BLKB 1 ;CONTROLLER INDEX 
S.STS: .BLKB I. ;CONTROLLER STATUS (OQ=IDLE, 1=BUSY) 
S.CSR: .BLKW 1 ;ADDRESS OF CONTROL STATUS REGISTER 
S.PKT: .BLKW AD ;ADDRESS OF CURRENT I/O PACKET 
S.FRK: .BLKW a FORK BLOCK LINK WORD 
S.DMCS: ;DM11-BB CSR FOR FDX TTDRV 

- BLKW 1 *FORK-—PC 

- BLKW 1 7FORK-R5 

- BLKW al ;FORK-R4 


-IF NB SYSDEF 

-IF DF LSSDRV & MSSMGE 

-BLKW 1 ;FORK-DRIVER RELOCATION BASE 
-ENDC ;LSSDRV & MSSMGE 


S<CCB? ;MIXED MASSBUS CHANNEL CONTROL BLOCK 


S.MPR: .BLKW 6 711/70 EXTENDED MEMORY UNIBUS DEVICE C-BLOCK 
- BLKW 1 ;BUFFER WORD 

S.UMHD: .BLKW 2 ;LIST HEAD FOR UMR ASSIGNMENT BLOCK (S) 

S.UMCT: .~BLKW 1 ;COUNT OF AVAILABLE UMR ASSIGNMENT BLOCK (S) 
oLEF 
~PSECT 


000000 
000002 
000004 
000006 
000010 
000011 
000012 


000014 
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; 
; STATUS CONTROL BLOCK PRIORITY BYTE CONDITION CODE STATUS BIT 
; DEFINITIONS 


‘ 

SP. EIP=1 
SP. ENB=2 
SP.LOG=4 
SPARE=10 


=e me NO 


- =0 
M.LNK: 
M.UMRA: 
M.UMRN: 
M.UMVL: 
M.UMVH: 
M.BFVH: 
M.BFVL: 


M.LGTH=. 


- ASECT 


- BLKW 
.- BLKW 
- BLKW 
. BLKW 
- BLKB 
.- BLKB 
. BLKW 


- ENDC 


- PSECT 


PRR RPP He 


7S YS DEF 


;ERROR IN PROGRESS (1=YES) 
ERROR LOGGING ENABLED (0=YES) 
;ERROR LOGGING AVAILABLE (1=YES) 
7;SPARE BIT 


MAPPING ASSIGNMENT BLOCK (FOR UNIBUS MAPPING REGISTER ASSIGNMENT) 


;LINK WORD 

s;ADDRESS OF FIRST ASSIGNED UMR 

;NUMBER OF UMR'S ASSIGNED * 4 

;LOW 16 BITS MAPPED BY 1ST ASSIGNED UMR 
HIGH 2 BITS MAPPED IN BITS 4 AND 5 
*;HIGH 6 BITS OF PHYSICAL BUFFER ADDRESS 
;LOW 16 BITS OF PHYSICAL BUFFER ADDRESS 


;LENGTH OF MAPPING ASSIGNMENT BLOCK 


C-38 


ANnAN 


000000 
000002 
000003 
000004 
000006 
000012 
000016 
000022 
000026 
000030 
000032 
000034 
000036 
000040 
000041 
000044 
000046 
000050 
000052 
000054 
000056 
000057 
000060 
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TCBDF$ 


TCBDF$ ,,SYSDEF 


TASK CONTROL BLOCK OFFSET AND STATUS DEFINITIONS 


TASK CONTROL BLOCK 


“=e Ne NO MO we 


- ASECT 
- =0 
T.LNK: .BLKW 
T.PRI: .BLKB 
T.LOCs~ -.~BLKB 
T.CPCB: .BLKW 
T.NAM: .BLKW 
T.RCVL: .«BLKW 
T.ASTL: .~BLKW 
T.EFLG: .BLKW 
T.UCB: .BLKW 
T.TCBL: .BLKW 
T.STAT: .BLKW 
T.ST2: .~BLKW 
T.ST3: .BLKW 
T. DPRIs «BLES 
T.LBN: .BLKB 
T.LDV: .BLKW 
T.PCB: .BLKW 
T.MXSZ: .~BLKW 
T.ACTL: .~BLKW 
T.SAST: .BLKW 

- BLKB 
T.TIO: .BLKB 
T.TKSZ: .BLKW 


;UTILITY LINK WORD 
;TASK PRIORITY 

;1/O PENDING COUNT 

;POINTER TO CHECKPOINT PCB 

;TASK NAME IN RADS5O 

;RECEIVE QUEUE LISTHEAD 

;AST QUEUE LISTHEAD 

;TASK LOCAL EVENT FLAGS 1-32 

;UCB ADDRESS FOR PSEUDO DEVICE 'TI! 
;TASK LIST THREAD WORD 

;FIRST STATUS WORD (BLOCKING BITS) 
;SECOND STATUS WORD (STATE BITS) 
;THIRD STATUS WORD (ATTRIBUTE BITS) 
;TASK'S DEFAULT PRIORITY 

;LBN OF TASK LOAD IMAGE 

;UCB ADDRESS OF LOAD DEVICE 

;PCB ADDRESS OF TASK PARTITION 
;MAXIMUM SIZE OF TASK IMAGE (MAPPED ONLY) 
;ADDRESS OF NEXT TASK IN ACTIVE LIST 
;SPECIFIED AST LISTHEAD 

;UNUSED BYTE 

;BUFFERED 1/0 COUNT 

;TASK SIZE (FROM LSBLDZ IN LABEL BLK) IN: 
UNMAPPED SYSTEMS - BYTES 

MAPPED SYSTEMS  - 32 WORD BLOCKS 
;TASK SIZE (FROM LSBMXZ IN LABEL BLK) 
;FOR RSX11S SYSTEMS ONLY 
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; MAPPED SYSTEMS - 32 WORD BLOCKS 
: UNMAPPED SYSTEMS —- BYTES 

SS$=. ;MARK START OF PLAS AREA 

T.ATT: .BLKW 2 ; ATTACHMENT DESCRIPTOR LISTHEAD 

T.OFF: .BLKW 1 ;OFFSET TO TASK IMAGE IN PARTITION 
;IF ASSHDR IS DEFINED, THIS WORD ALSO 
;INCLUDES THE LENGTH OF THE ALTERNATE 
;HEADER REFRESH AREA STORED IN T.HDLN 

. BLKB a ; RESERVED 
T.SRCT: .BLKB 1 ;SREF WITH EFN COUNT IN ALL RECEIVE QUEUES 
T.RRFL: .BLKW 2 ;RECEIVE BY REFERENCE LISTHEAD 


.iF NDF PSSLAS 
~=$$5S ;POINT TO START OF PLAS AREA 
-ENDC ;PSSLAS 
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-IF NB SYSDEF 


$$S$=. *MARK START OF PARENT OFFSPRING TASKING AREA 
T.OCBH: .BLKW 2 ;OFFSPRING CONTROL BLOCK LISTHEAD 
T.RDCT: .~BLKW 1 ;OUTSTANDING OFFSPRING COUNT 


.IF NDF PSSOFF 
-=SS$ POINT TO START OF PARENT OFFSPRING AREA 
~ENDC ;PSSOFF 


$$$=. *MARK START OF EVENT FLAG MASK AREA 
T.EFLM: .~BLKW 2 ;EVENT FLAG MASK WORD 
;EVENT FLAG MASK ADDRESS 


.IF NDF SSSTOP & TSSBUF 
-=SSS$ ;POINT TO START OF EVENT FLAG MASK AREA 
~-ENDC ;SSSTOP & TSSBUF 


S$$=. 
T.HDLN: .BLKB- 1 ;TASK HEADER LENGTH IN 32-WORD BLOCKS 


.IF NDF ASSHDR 
~=SSS :;NOT SUPPORTED IF NDF 
~ENDC ;ASSHDR 


em -BLKB 1 ;GROUP GLOBAL USE COUNT FOR TASK 
.IF NDF GSSEFN ! RSSSND 

ee -ENDC ;GSSEFN ! RSSSND 
. EVEN 

T. LGTH=. ;LENGTH OF TASK CONTROL BLOCK 

T. EXT=0 ;LENGTH OF TCB EXTENSION 
.IFF 


TASK STATUS DEFINITIONS 


FIRST STATUS WORD (BLOCKING BITS) 


e Se we Be we 
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TS. EXE=100000 ;TASK NOT IN EXECUTION (1=YES) 

TS. RDN=40000 7I/O RUN DOWN IN PROGRESS (1=YES) 
TS.MSG=20000 ; ABORT MESSAGE BEING OUTPUT (1=YES) 
TS.NRP=10000 ;TASK MAPPED TO NONRESIDENT PARTITION (1=YES) 
TS. RUN=4000 TASK IS RUNNING ON ANOTHER PROCESSOR (1=YES) 
TS.HLD=2000 ;TASK HALF-LOADED BY TASK LOADER 

TS.STP=1000 7;TASK EXTERNALLY BLOCKED VIA CLI COMMAND 

TS. OUT=400 TASK IS OUT OF MEMORY (1=YES) 

TS.CKP=200 ;TASK IS BEING CHECKPOINTED (1=YES) 
TS.CKR=100 ;TASK CHECKPOINT REQUESTED (1=YES) 
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; 
; TASK BLOCKING STATUS MASK 
i 
T 


S.BLK=TS.CKP!TS.CKR!ITS. EXE!TS.MSG!ITS.NRP!ITS. OUT!ITS. RDN!ITS.STP 


SECOND STATUS WORD (STATE BITS) 


ee =e me 


s 

T2.AST=100000 ;AST IN PROGRESS (1=YES) 

T2.DST=40000 ;AST RECOGNITION DISABLED (1=YES) 
T2.CHK=20000 7TASK NOT CHECKPOINTABLE (1=YES) 
T2.CKD=10000 ;CHECKPOINTING DISABLED (1=YES) 
T2.SEF=4000 ;TASK STOPPED FOR EVENT FLAGS (1=YES) 
T2.FXD=2000 ;TASK FIXED IN MEMORY (1=YES) 
T2.REX=1000 ;ABORT AST EFFECTED OR IN PROGRESS (1=YES) 
T2.CAF=400 ;DYN CHECKPOINT SPACE ALLOCATION FAILURE 
T2.HLT=200 ;TASK IS BEING HALTED (1=YES) 

T2.ABO=100 ;TASK MARKED FOR ABORT (1=YES) 

T2.STP=40 7;SAVED T2.STP ON AST IN PROGRESS 
T2.STP=20 7TASK STOPPED (1=YES) 

T2.SPN=10 ;SAVED T2.SPN ON AST IN PROGRESS 
T2.SPN=4 7TASK SUSPENDED (1=YES) 

T2.WFR=2 ;SAVED T2.WFR ON AST IN PROGRESS 
T2.WFR=1] ;TASK IN WAITFOR STATE (1=YES) 


THIRD STATUS WORD (ATTRIBUTE BITS) 


ome MO 


’ 

T3.ACP=100000 ; ANCILLARY CONTROL PROCESSOR (1=YES) 
T3.PMD=40000 7DUMP TASK ON SYNCHRONOUS ABORT (0=YES) 

T3. REM=20000 ;REMOVE TASK ON EXIT (1=YES) 

T3. PRV=10000 ;TASK IS PRIVILEGED (1=YES) 

T3.MCR=4000 7;TASK REQUESTED AS EXTERNAL MCR FUNCTION (1=YES) 
T3.SLV=2000 ;TASK IS A SLAVE TASK (1=YES) 

T3.CLI=1000 ;TASK IS A COMMAND LINE INTERPRETER (1=YES) 
T3.RST=400 ;TASK IS RESTRICTED (1=YES) 

T3.NSD=200 ;TASK DOES NOT ALLOW SEND DATA 

T3.CAL=100 ;TASK HAS CHECKPOINT SPACE IN TASK IMAGE 
T3.ROV=40 ;TASK HAS RESIDENT OVERLAYS 

T3.NET=20 ;NETWORK PROTOCOL LEVEL 

T3.GFL=10 ;TASK HAS ITS GRP GBL EVENT FLAGS LOCKED 

; =4 RESERVED FOR FUTURE USE 

T3.SWS=2 RESERVED FOR USE BY SOFTWARE SERVICES 

; =1 RESERVED FOR FUTURE USE 


~ENDC ;SYSDEF 


« PSECT 
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UCBDF$ 


UCBDF$ ,,TTDEF,SYSDEF 


UNIT CONTROL BLOCK 


THE UNIT CONTROL BLOCK (UCB) DEFINES THE STATUS OF AN INDIVIDUAL 
DEVICE UNIT AND IS THE CONTROL BLOCK THAT IS POINTED TO BY THE 
FIRST WORD OF AN ASSIGNED LUN. THERE IS ONE UCB FOR EACH DEVICE 
UNIT OF EACH DCB. THE UCB'S ASSOCIATED WITH A PARTICULAR DCB ARE 
CONTIGUOUS IN MEMORY AND ARE POINTED TO BY THE DCB. UCB'S ARE 
VARIABLE LENGTH BETWEEN DCB'S BUT ARE OF THE SAME LENGTH FOR A 
SPECIFIC DCB. TO FINISH THE TELETYPE EXAMPLE ABOVE, EACH UNIT ON 
BOTH INTERFACES WOULD HAVE A UCB. 
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~ ASECT 
-IF NB SYSDEF 
~IF DF ESSDVC 
-IF DF MSSMUP ;IS U.OWN THERE? 
-=177766 
» LFF 
-=177770 
~ENDC ;MSSMUP 
U.I0C: .BLKW 2 71/0 COUNT SINCE MOUNT (ERROR LOG DEVS ONLY) 
U.ERSL: .BLKB it ;SOFT ERROR LIMIT 
U.ERHL: .BLKB 1 ;HARD ERROR LIMIT 
U.ERSC: .BLKB 1 ;SOFT ERROR COUNT 
U.ERHC: .BLKB 1 ;HARD ERROR COUNT 
-ENDC ;ESSDVC 
~ENDC ;SYSDEF 
~=177772 
177772 U.MUP: ;MULTIUSER PROTECTION FLAG WORD 
177772 U.CLI: .BLKW 1 ;TCB OF COMMAND LINE INTERPRETER 
177774 U.LUIC: .~BLKW i ;LOGIN UIC - MULTI USER SYSTEMS ONLY 
177776 U.OWN: .BLKW 1 ;OWNING TERMINAL - MULTI USER SYSTEMS ONLY 
000000 U.DCB: .BLKW 1 :;BACK POINTER TO DCB 
000002 U.RED: .BLKW 1 ;POINTER TO REDIRECT UNIT UCB 
000004 U.CTL: .BLKB 1 ;CONTROL PROCESSING FLAGS 
000005 U.STS: .BLKB 1 ;UNIT STATUS 
000006 U.UNIT: .BLKB 1 ;PHYSICAL UNIT NUMBER 
000007 U.ST2: .BLKB 1 ;UNIT STATUS EXTENSION 
000010 U.CW1l: .BLKW 1 ;FIRST DEVICE CHARACTERISTICS WORD 
000012 U.CW2: .BLKW 1 ;SECOND DEVICE CHARACTERISTICS WORD 
000014 U.CW3: .BLKW 1 ;THIRD DEVICE CHARACTERISTICS WORD 
000016 U.CW4: .BLKW u ;FOURTH DEVICE CHARACTERISTICS WORD 
000020 U.SCB: .BLKW 1 ;POINTER TO SCB 
000022 U.ATT: .BLKW L ;TCB ADDRESS OF ATTACHED TASK 
000024 U.BUF: .BLKW 1 ;RELOCATION BIAS OF CURRENT I/O REQUEST 
000026 - BLKW iL ;BUFFER ADDRESS OF CURRENT I/0 REQUEST 
000030 U.CNT: .BLKW Al ;BYTE COUNT OF CURRENT I/O REQUEST 


000032 
000034 
000032 
000032 
000034 


000036 
000036 
000040 
000042 


000036 
000040 
000044 


000050 
000052 
000054 
000060 
000070 
000074 
000076 
000100 
000102 
000104 
000110 
000112 
000113 


000114 
000120 


000024 
000026 
000034 
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U.ACP=U.CNT+2 ADDRESS OF TCB OF MOUNTED ACP 

U. VCB=U.CNT+4 ;ADDRESS OF VOLUME CONTROL BLOCK 
U.CBF=U.CNT+2 ;CONTROL BUFFER RELOCATION AND ADDRESS 
U. KCSR=U.CNT+2 7CSR ADDRESS OF KMC-11 

U. KCS6=U. KCSR+2 7;CSR+6 OF KMC-11 

; 

; MAGTAPE DRIVER DEFINITIONS 

a 

U.SPC=U .CNT+6 ;SPACING COUNT 

U.SUB=U.CNT+6 ;SUBCONTROLLER, PHYSICAL UNIT #. 

U. FNUM=U.CNT+10 ; FORMATTER NUMBER 

U. FCDE=U.CNT+12 ;FUNCTION CODE AND INDEX 

: MSCP DISK DRIVER UCB OFFSETS 

7 

U.UTMO=U. VCB+2 UNIT COMMAND TIME OUT 

U. LHD=U. VCB+4 ;UNIT OUTSTANDING I/O PACKET LISTHEAD 
U.BPKT=U. VCB+10 UNIT BAD BLOCK PACKET WAITING LIST 

; 

; CHARACTERISTICS OBTAINED FROM "GET UNIT STATUS" END PACKETS 
f 

U.MLUN=U. VCB+14 ;MULTI-UNIT CODE 

U.UNFL=U.VCB+16 ;UNIT FLAGS 

U.HSTI=U. VCB+20 ;HOST IDENTIFIER 

U.UNTI=U. VCB+24 ;UNIT IDENTIFIER 

U.MEDI=U. VCB+34 ;MEDIA IDENTIFIER 

U.SHUN=U. VCB+40 ;SHADOW UNIT 

U.SHST=U. VCB+42 ;SHADOW UNIT STATUS 

U.TRCK=U. VCB+44 ;UNIT TRACK SIZE 

U.GRP=U.VCB+46 ;UNIT GROUP SIZE 

U.CYL=U.VCB+50 ;UNIT CYLINDER SIZE 

U.RCTS=U.VCB+54 ;UNIT RCT TABLE SIZE 

U. RBNS=U. VCB+56 ;UNIT RBN 'S / TRACK 

U. RCTC=U. VCB+57 UNIT RCT COPIES 

; 

; CHARACTERISTICS OBTAINED FROM "ONLINE" OR "SET UNIT CHARACTERISTICS" 
; END PACKETS 

’ 

U.UNSZ=U. VCB+60 ;UNIT SIZE 

U. VSER=U. VCB+64 ; VOLUME SERIAL NUMBER 


; 
; TERMINAL DRIVER DEFINITIONS 
; 


=U.BUF 
U.TUX: .BLKW 
U.TSTA: .BLKW 
U.TTAB: .BLKW 


POINTER TO UCB EXTENSION (UCBX) 

;STATUS TRIPLE-WORD 

7IF O: U.TTAB+1 IS SINGLE-CHARACTER TYPE-AHEAD 

; BUFFER, CURRENTLY EMPTY 

IF ODD: U.TTAB+1 IS SINGLE-CHARACTER 
TYPE-AHEAD BUFFER AND HOLDS A 
CHARACTER 

IF NON-O AND EVEN: POINTER TO MULTI-CHARACTER 

; TYPE-AHEAD BUFFER 


eee) 


me %e Me NO ON 


] 


000036 
000037 
000040 
000042 
000043 
000044 
000046 
000047 
000050 
000052 
000054 
000056 


000030 
000032 
000036 
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U.TLPP: .BLKB 
U.TFRO: .~BLKB 
U.TFLK: .BLKW 
U.TCHP: .BLKB 
U.TCVP: .BLKB 
U.UIC: .BLKW 
U.TTYP: .BLKB 
U.TMTI: .BLKB 
U.CTYP: .BLKW 
U.ACB: .BLKW 
U.AFLG: .BLKW 
U.ADMA: .BLKW 


e =e “te OS 


=U.CNT 

U.CTCB: .~BLKW 
U.COTQ: .~BLKW 
U.RED2: .BLKW 


$1. RST=1 

S1. RUB=2 
S1.ESC=4 
S1.RAL=10 
S1. RNE=20 
S$1.CTO=40 
S1. OBY=100 
S1.IBY=200 
S1.BEL=400 
S1.DPR=1000 
S51. DEC=2000 
S1.DSI=4000 
S1.CTS=10000 
$1.USI=20000 


S1. OBF=40000 
$1. IBF=100000 


e me ma 


$2. ACR=1 
S2.WRA=6 
S2.WRB=2 
$2.CR=10 
$2.BRQ=20 
S2.SRQ=40 


$2. ORQ=100 
$2. IRQ=200 
$2. HFL=3 400 
$2. VFL=4000 
52. HHT=10000 
$2. HFF=20000 
52. FLF=40000 
$2. FDX=100000 


ee 


DEFINE BITS IN STATUS 


DEFINE BITS IN STATUS 


;LINES PER PAGE 

;FORK REQUEST BYTE 

;FORK LIST LINK WORD 

;CURRENT HORIZONTAL POSITION 
;CURRENT VERTICAL POSITION 

;TERMINAL UIC 

;TERMINAL TYPE 

;MODEM TIMER 

;CONTROLLER TYPE 

;ANCILLARY CONTROL DRIVER BLOCK ADDR 
;ANCILLARY CONTROL DRIVER FLAGS WORD 
;ANCILLARY CONTROL DRIVER DMA BUFFER 


CONSOLE DRIVER DEFINITIONS 


;ADDRESS OF CONSOLE LOGGER TCB 
71/0 PACKET LIST QUEUE 
REDIRECT UCB ADDRESS 


WORD 1 (U.TSTA) 


;READ WITH SPECIAL TERMINATORS IN PROGRESS 


;RUBOUT SEQUENCE IN PROGRESS (NON-SCOPE) 
; ESCAPE SEQUENCE IN PROGRESS 

;READ ALL IN PROGRESS 

;ECHO SUPPRESSED 

;OUTPUT STOPPED BY CTRL-O 

;OUTPUT BUSY 

; INPUT BUSY 

;BELL PENDING 

;DEFER PROCESSING OF CHAR. IN U.TECB 
;DEFER ECHO OF CHAR. IN U.TECB 

; INPUT PROCESSING DISABLED 

;OUTPUT STOPPED BY CTRL-S 

; UNSOLICITED INPUT IN PROGRESS 

;BIT 14 RESERVED FOR NON-BUFFERED OUTPUT 
;BUFFERED OUTPUT IN PROGRESS 

;BUFFERED INPUT IN PROGRESS 


WORD 2 (U.TSTA+2) 


;WRAP-AROUND (AUTOMATIC: CR-LF) REQUIRED 
;CONTEXT FOR WRAP-AROUND 

;LOW BIT IN S2.WRA BIT PATTERN 

; TRAILING CR REQUIRED ON OUTPUT 

; BREAK-THROUGH-WRITE REQUEST IN QUEUE 
;SPECIAL REQUEST IN QUEUE 

; (IO.ATT, IO.DET, SF.SMC) 

;OUTPUT REQUEST IN QUEUE (MUST = S1.OBY) 
7; INPUT REQUEST IN QUEUE (MUST = S1.IBY) 
;HORIZONTAL FILL REQUIREMENT 

; VERTICAL FILL REQUIREMENT 

;HARDWARE HORIZONTAL TAB PRESENT 
;HARDWARE FORM-FEED PRESENT 

; FORCE LINE FEED BEFORE NEXT ECHO 

;LINE IS IN FULL DUPLEX MODE 
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e 
? 
e 
f 

° 

’ 
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3. RAL=10 


S3.RPO=20 
S3.WES=40 
S3. TAB=100 
$3. 8BC=200 
S3.RCU=400 
$3.ABD=1000. 
S3.ABP=2000 
S3.WAL=4000 
S3.VER=10000 


S3.BCC=20000 


S3.DA0=40000 


$3. PCU=100000 


- PSECT 


DV. REC=1 
DV. CCL=2 
DV. TTY=4 
DV. DIR=10 
DV. SDI=20 
DV. SQD=40 
DV.MSD=100 
DV. UMD=200 
DV.MBC=400 
DV. EXT=400 
DV. SWL=1000 
DV. ISP=2000 
DV. OS P=4000 
DV. PSE=10000 


DV. COM=20000 
DV. F11=40000 


DEFINE BITS IN STATUS 


WORD 3 (U.TSTA+4) 


; TERMINAL IS IN READ~PASS-ALL MODE 
;(S3.RAL MUST = $1.RAL) 

;READ W/PROMPT OUTPUT IN PROGRESS 

;TASK WANTS ESCAPE SEQUENCES 
;TYPE-AHEAD BUFFER ALLOCATION REQUESTED 
;PASS 8 BITS ON INPUT 

;RESTORE CURSOR (MUST = TF.RCU*400) 
;AUTO-BAUD SPEED DETECTION ENABLED 
;AUTO-BAUD SPEED DETECTION IN PROGRESS 
;WRITE-PASS-ALL (MUST = TF.WAL*400) 
;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS PARITY ERROR 

;LAST CHAR. IN TYPE-AHEAD BUFFER 

;HAS FRAMING ERROR 

;LAST CHAR. IN TYPE-AHEAD BUFFER 

:HAS DATA OVERRUN ERROR 

;NOTE - THE 3 BITS ABOVE MUST CORRESPOND 
;TO THE RESPECTIVE ERROR FLAGS IN THE 
;HARDWARE RECEIVE BUFFER 

;POSITION CURSOR (MUST = TF.PCU*400) 


DEVICE TABLE STATUS DEFINITIONS 


DEVICE CHARACTERISTICS WORD 1 (U.CW1) DEVICE TYPE DEFINITION BITS. 


;RECORD ORIENTED DEVICE (1=YES) 
;CARRIAGE CONTROL DEVICE (1=YES) 

;TERMINAL DEVICE (1=YES) 

;FILE STRUCTURED DEVICE (1=YES) 

;SINGLE DIRECTORY DEVICE (1=YES) 
;SEQUENTIAL DEVICE (1=YES) 

;MASS STORAGE DEVICE (1=YES) 

;USER MODE DIAGNOSTICS SUPPORTED (1=YES) 
;DEVICE IS ON MASSBUS CONTROLLER (1=YES) 
;DEVICE ON EXTENDED ADDRESSING CONTROLLER 
;UNIT SOFTWARE WRITE LOCKED (1=YES) 

; INPUT SPOOLED DEVICE (1=YES) 

OUTPUT SPOOLED DEVICE (1=YES) 

;PSEUDO DEVICE (1=YES) 

;DEVICE IS MOUNTABLE AS COM CHANNEL (1=YES) 
;DEVICE IS MOUNTABLE AS Fll DEVICE (1=YES) 


DV.MNT=100000 ;DEVICE IS MOUNTABLE (1=YES) 


TERMINAL DEPENDENT CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 


e me Ne 


U2. DH1=100000 ;UNIT IS A MULTIPLEXER (1=YES) 


U2.DJ1=40000 
U2. RMT=20000 
U2. HFF=10000 
U2. L8S=10000 
U2.NEC=4000 
U2.CRT=2000 
U2. ESC=1000 
U2, LOG=400 
U2.SLV=200 
U2.DZ1=100 


;UNIT IS A DJll (1=YES) 

;UNIT IS REMOTE (1=YES) 

;UNIT HANDLES HARDWARE FORM FEEDS (1=YES) 
;OLD NAME FOR U2.HFF 

;DON'T ECHO SOLICITED INPUT (1=YES) 

;UNIT IS A CRT (1=YES) 

;UNIT GENERATES ESCAPE SEQUENCES (1=YES) 
;USER LOGGED ON TERMINAL (0=YES) 

;UNIT IS A SLAVE TERMINAL (1=YES) 

;UNIT IS A DZ1l (1=YES) 
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U2. HLD=40 ;TERMINAL IS IN HOLD SCREEN MODE (1=YES) 
U2.AT.=20 ;MCR COMMAND AT. BEING PROCESSED (1=YES) 

U2. PRV=10 ;UNIT IS A PRIVILEGED TERMINAL (1=YES) 
U2.L3S=4 UNIT IS A LA30S TERMINAL (1=YES) 

U2.SCS=4 ;SCS-11 COMMAND TERMINAL (1=YES) 

U2. VT5=2 ;UNIT IS A VTO5B TERMINAL (1=YES) 

U2. LWC=1 ;LOWER CASE TO UPPER CASE CONVERSION (0=YES) 


; 
; BIT DEFINITIONS FOR U.MUP (SYSTEMS WITH ALTERNATE CLI SUPPORT ONLY) 


; 

UM.OVR=1 ;OVERRIDE CLI INDICATOR 

UM.CLI=36 ;CLI INDICATOR BITS 

UM. DSB=200 ; TERMINAL DISABLED SINCE CLI ELIMINATED 
UM. NBR=400 ;NO BROADCAST 

i 

7 RH11-RS03/RS04 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 
i 

U2.R04=100000 ;UNIT IS A RSO4 (1=YES) 

i 

7 RH11-TU16 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS 

i 

U2. 7CH=10000 ;UNIT IS A 7 CHANNEL DRIVE (1=YES) 

; 

; TERMINAL DEPENDENT CHARACTERISTICS WORD 3 (U.CW3) BIT DEFINITIONS 
7 

U3. UPC=20000 ;UPCASE OUTPUT FLAG 


. 
f 
. 

’ 


UNIT CONTROL PROCESSING FLAG DEFINITIONS 


f 

UC. ALG=200 ;BYTE ALIGNMENT ALLOWED (1=NO) 
UC.NPR=100 ;DEVICE IS AN NPR DEVICE (1=YES) 

UC. QUE=40 ;CALL DRIVER BEFORE QUEUING (1=YES) 

UC. PWF=20 ;CALL DRIVER AT POWERFAIL ALWAYS (1=YES) 
UC.ATT=10 ;CALL DRIVER ON ATTACH/DETACH (1=YES) 
UC. KIL=4 ;CALL DRIVER AT I/O KILL ALWAYS (1=YES) 
UC. LGH=3 ; TRANSFER LENGTH MASK BITS 


UNIT STATUS BIT DEFINITIONS 


° 
f 
e 
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US.BSY=200 ;UNIT IS BUSY (1=YES) 

US.MNT=100 ;UNIT IS MOUNTED (0=YES) 

US. FOR=40 ;UNIT IS MOUNTED AS FOREIGN VOLUME (1=YES) 
US.MDM=20 ;UNIT IS MARKED FOR DISMOUNT (1=YES) 

US. PWF=10 ;POWERFAIL OCCURRED (1=YES) 


CARD READER DEPENDENT UNIT STATUS BIT DEFINITIONS 


~e “Se we 


US. ABO=1 ;UNIT IS MARKED FOR ABORT IF NOT READY (1=YES) 
US.MDE=2 ;UNIT IS IN 029 TRANSLATION NODE (1=YES) 
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i 
; FILES-11 DEPENDENT UNIT STATUS BITS 


a 

US.WCK=10 ;WRITE CHECK ENABLED (1=YES) 
US. SPU=2 ;UNIT IS SPINNING UP (1=YES) 
US. VW=1 ;VOLUME VALID IS SET (1=YES) 
3 

+ KMC-11-LP DEPDENDENT UNIT STATUS BITS 

US. KPF=1 7KMC-11 POWERFAIL INTERLOCK 


TERMINAL DEPENDENT UNIT STATUS BIT DEFINITIONS 


=e =e Me 


IF NB TTDEF 


.IF DF TSSCPW 


US. CRW=4 ;UNIT IS WAITING FOR CARRIER (1=YES) 
US. DSB=2 ;UNIT IS DISABLED (1=YES) 
US. OIU=1 ;OUTPUT INTERRUPT IS UNEXPECTED ON UNIT (1=YES) 


~IFF ;TSSCPW 


US. DSB=10 ;UNIT IS DISABLED (1=YES) 

US.CRW=4 ;UNIT IS WAITING FOR CARRIER (1=YES) 

US. ECH=2 ;UNIT HAS ECHO IN PROGRESS (1=YES) 

US. OUT=1 ;UNIT IS EXPECTING OUTPUT INTERRUPT (1=YES) 


~ENDC ;TSSCPW 


~ENDC ;TTDEF 


LPS11 DEPENDENT UNIT STATUS BIT DEFINITIONS 


o ~e fe 


’ 
US. FRK=2 ;FORK IN PROGRESS (1=YES) 
US.SHR=1 ;SHAREABLE FUNCTION IN PROGRESS (0=YES) 


MAGTAPE DEPENDANT UNIT STATUS BITS 


e ™e "Oe 


US. LAB=4 ;UNIT HAS LABELED TAPE ON IT (1=YES) 
US.BSP=2 ; INTERNAL BACKSPACE IN PROGRESS (1=YES) 


e ™e we 


f 

US. OFL=1 
US. RED=2 
US. PUB=4 
US. UMD=1 


MAG TA 


e ™e te MO 


UD. UNS=0 
UD. 200=1 
UD. 556=2 
UD. 800=3 
UD. 160=4 
UD. 625=5 
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0 


PE DENS SUPPORT 
ASSIGNMENTS PER 


UNIT STATUS EXTENSION (U.ST2) BIT DEFINITIONS 


;UNIT OFFLINE (1=YES) 

;UNIT REDIRECTABLE (0=YES) 

;UNIT IS PUBLIC DEVICE (1=YES) 

;UNIT ATTACHED FOR DIAGNOSTICS (1=YES) 


IDENT IN CHAR WORD 3 (U.CW3) DEFENITION 
NUMERICAL SEQUENCE 0 - 255. 


; UNSUPPORTED 

200BPI, 7 TRACK 
556BPI, 7 TRACK 
800BPI, 7 OR 9 TRACK 
;1600BPI, 9 TRACK 
;6250BPI, 9 TRACK 


me =e Se 


APPENDIX D 


USER-WRITTEN ANCILLARY CONTROL PROCESSORS 


This chapter is intended as a guide for the user in developing an 
Ancillary Control Processor (ACP). It is not a tutorial and it is not 
a description of the logic of any DIGITAL-supplied ACP. You should be 
thoroughly familiar with the RSX-11M Guide to Writing an I/O Driver. 


This chapter provides the following information: 
e An overview of the RSX-11M I/0 system 
e Descriptions of the types of ACPs 
e The attributes of an ACP 


e A description of the flow of an input/output request, 
emphasizing the role of the ACP 


e System data structures used by the ACPs 


e Examples of an ACP and an I/O driver 


D.1 OVERVIEW OF THE RSX-11M I/O SYSTEM 


An Ancillary Control Processor (ACP) is one component of the RSX I/0 
system. The other major components are 


e File Control Services (FCS) or Record Management Services 
(RMS) 


e QIOS directive processing in the Executive 
e Device drivers 
Figure D-l shows how an ACP fits into the overall structure. 
The philosophy and structure of the RSX-11M I/O system are described 


in detail in Chapter 2 of this manual. QIOS directive processing is 
described in the RSX-11M/M-PLUS Executive Reference Manual. 
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User Task 


-}- 


FCS 


ZK-227-81 


Figure D-l1 The RSX-11M I/0 System 


D.2 TYPES OF ANCILLARY CONTROL PROCESSORS 
An Ancillary Control processor (ACP) is a task that provides extended 
functions (complex operations requiring either multiple I/O requests 
or special privileged operations) for a class of I/O devices. 
ACPs may be divided into three types: 

e Those that manage file structures, such as FI1ACP and MTAACP 


e Those that manage intertask or interprocessor communication, 
such as the network ACP (NETACP) 


e Those that perform special privileged operations on behalf of 
nonprivileged user tasks. 


USER-WRITTEN ANCILLARY CONTROL PROCESSORS 


Some of the purposes of a uSer-written ACP are: 
e To implement a foreign file system 
e To extend the capabilities of a DIGITAL-supplied device driver 
e To extend the services of the operating system 
e To implement a communications protocol 


User-written ACPs extend functionality, not performance. If your 
application is performance-oriented, you should consider writing a 
special driver rather than an ACP. 


D.2.1 ACPs Which Manage Files Structures 


DIGITAL suppiies FIiACP for Files-ii disk structure and MTAACP for 
ANSI magnetic tapes. You may write an ACP to implement a foreign file 
system or tape format. Changes to the Executive, the I/O driver, or 
the data structures are not necessary if there are DIGITAL-supplied 
I/O operations that correspond to operations for the foreign format. 
The uSer-written ACP can uSe the built-in Executive Services (such as 
QIO$ directive processing) without change. 


Note that a user-written ACP is necessary only to support a file 
Structure other than Files-ll. To use the Files-1l structure with a 
foreign device, you need to write a device driver, and you may need to 
modify or extend disk initialization, management, or backup utilities. 


D.2.2 ACPs Which Manage Intertask or Interprocessor Communication 


DECnet/M and DECnet/M-PLUS both contain an example of an ACP that 
manages interprocessor communications: NETACP, used for management of 
the Digital Network Architecture Communications protocol. You may 
write an ACP to manage a foreign communications protocol. 


D.2.3 ACPs Which Perform Privileged Operations for Unprivileged Tasks 


You may write an ACP to support extended capabilities for a class of 
devices (such as line printer spooling or associative name searching 
for data base devices). This requires special support in the 
Executive I/O processing, in the I/O driver, and in the associated 
data structures. This type of ACP requires a user-written I/O driver 
that contains special code to support the ACP. 


An ACP may use the I/O driver interface to extend the services of the 
operating system (as in the case of a data base management system), 
rather than to extend the services of an I/O device. 


RSX-11M contains no DIGITAL-supplied examples of the types just 
described. Both RSX-11M and RSX-11M-PLUS, however, contain COT and 
CODRV, which are used to perform console logging. The COT task 
behaves in the fashion of an ACP, in that it receives I/O packets in 
its queue from user tasks. COT is not declared to the system as an 
ACP, though; it has no VCB or MOU interface. COT is enabled and 
disabled using MCR commands. 
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D.3 THE ATTRIBUTES OF AN ACP 


The classes of ACPs described above have the following attributes in 
common, which further define an ACP: 


e An ACP is an asynchronous’ privileged task. Refer to the 
RSX-11M/M-PLUS Task Builder Manual for a discussion of 
privileged task mapping and Executive access. 


@ An ACP implements a protocol (or set of services) for a class 
of devices (for example, file-structured devices or sequential 
devices). 


e An ACP functions as an extension of the Executive and 
frequently operates with Executive privilege. 


@e An ACP can be enabled or disabled for a particular device. 


e An ACP is shareable among several device drivers and units. 


D.3.1 ACP as a Task 
An ACP is a task. It has all the attributes of a task, including: 
e A stack 
e A task name 
e Priority 
e Scheduling by the Executive 


An ACP, in contrast to a driver, operates aS a task. While a driver 
handles interrupts, manipulates CSRs, and performs other 
device-specific operations, an ACP is not device bound and can _ take 
advantage of the services and control mechanisms available to tasks. 
ACPs can also use overlays, and can therefore be larger and have 
greater functionality than drivers. 


Because the ACP task is privileged, it has access to the Executive 
data structures and can use Executive facilities. 


Unlike other privileged tasks, an ACP has the capacity to receive I/0 
packets from other tasks by means of the QIOS directive. This permits 
the ACP to act as an I/O handler, which can compete with user’ tasks 
for system resources more equitably than an I/O driver could. Also, 
unlike an I/O driver, an ACP can perform I/O to other devices during 
the processing of an I/O request. 


D.3.2 Class of Devices 


An ACP can easily implement functions for a class of devices because 
it communicates via the QIO$ directive, which is relatively 
device-independent. (Drivers, in contrast, are written to suit the 
minute peculiarities of particular devices.) FI1lACP, for example, 
implements the Files-1l structure for all types of disks and DECtapes. 
MTAACP implements ANSI magnetic tape format for all DIGITAL-supported 
9-track magnetic tape drives. 
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D.3.3 Extension of Executive 


An ACP extends the functionality of both the Executive and the device 
drivers in several ways: 


e By removing the burden of device managment (assigning space on 
a volume, locating the desired data area, and so on) from the 
programmer. 


e@ By handling the manipulation of device- and protocol-related 
data. 


e By permitting a device to be treated as a logical rather’ than 
a physical entity. 


e By allowing a device to be shared for simultaneous’ access. 
Each process that accesses a device is protected from other 


processes by the ACP and its protocol. The ACP also 
synchronizes access to the physical device. 


D.3.4 Enabling Capability and Disabling Capability 
An ACP can be enabled or disabled for a given device. When enabled, 


the device is available for use in the context of the protocol 
provided by the ACP. 


D.3.5 Shareability 


An ACP is shareable among several device drivers and units. 


D.4 THE FLOW OF AN I/O REQUEST 
This section describes the system interactions of an ACP during the 
flow of an I/O request. On the assumption that you have read Section 
2.6 of this manual, only those items relevant to ACPs are treated in 
detail. The structure of this section is similar to that of Section 
2. 6. 
The I/O flow proceeds as described below: 
1. [Task issues a QIOS directive] 
The Executive performs the following: 
a. First-level validity checks 
b. Redirect algorithm 
c. Additional validity checks 
2. [Executive obtains storage for and creates I/O packet] 


3. [Executive validates the function requested] 


If the function is an ACP function, the type of function 
validation depends on the type of ACP. 
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a. Standard DIGITAL-supplied ACP 


If the device is mounted with an ACP, the function 
code is validated to determine that it is an ACP 
function. The parameters are verified by code in the 
QIO processing module. The request is checked for 
proper order (for example, OPEN before CLOSE) and for 
valid buffers. The task that issues the I/O request 
must validate any additional parameter block required 
by the ACP, For some functions, an additional 
parameter buffer is allocated and filled in. 


Sometimes the I/O request can be transformed into a 
transfer function and queued to the proper driver. 
If the request cannot be queued to the driver or 
cannot be completed immediately, it is queued to the 
ACP. The request packet is inserted in the ACP's 
receive data queue and the ACP is’ unstopped or 
requested to run (depending on whether it was 
active). 


b. Nonstandard ACPs and ACPs requiring special Executive 
or driver support 


The QIOS$S directive processing cannot validate the ACP 
function request parameters. The I/O driver must do 
the validation. The UC.QUE bit in the driver must be 
set so that the QIO processing routine calls the 
driver directly, without queuing the I/O packet to 
the driver or to the ACP. 


The driver must perform the same functions for the 
ACP as the QIO processing code does for standard and 
replacement ACPs. 


(Driver processing] 


If the driver calls S$GTPKT and the next request in the queue 
is an ACP function request, SGTPKT will queue the request to 
the ACP and activate the ACP, 


[ACP processing] 
Obtain Work 


As soon as the ACP is activated, it attempts to remove an I/0 
request packet from its receive data queue. To do this, the 
ACP switches to system state and calls SQRMVF to obtain the 
address of the I/O packet. (Note that the ACP does not uSe 
the RCVDS directive to remove the packet from its_ receive 
queue.) When the ACP has obtained the address of the I/0 
packet, it returns to task state. 


Process I/O Request 

The ACP either completes the I/O request or translates it 
into a standard I/O driver request. The decision is based 
on: 

e Information in the data structures 


e Computation 


e Additional I/0 
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The ACP may do its own QIO requests to the driver; the ACP then 
calls SIOFIN with the I/O packet and the I/O status. 
Alternatively, when the I/O request is translated into a driver 
request, the ACP modifies the I/O packet to put it into the 
correct form for a driver request and passes it to the driver by 
calling S$DROQRQ. If the I/O request has been completed, the ACP 
calls SIOFIN with the I/O packet and the I/O status. 


For example, MTAACP always deals with the driver through QIO 
requests, and finishes I/O itself by calling SIOFIN. 


The ACP then attempts to remove another request from itS queue. 


If there are no more requests in the queue, the ACP stops itself 
by calling S$STPCT. 


D.5 SYSTEM DATA STRUCTURES 


An ACP interfaces to the system through use of system data Structures 
and through calls to Executive routines. This section describes 
ACP-specific information for the various data structures. Detailed 
information on the data structures and their interrelationships is 
contained in Section 2.7 and Chapter 4 of this manual. 


The following data structures comprise the complete set for I/0 
processing: 


e Task header 
e Window Block (WB) 
e File Control Block (FCB) 


e SDEVHD word, the Device Control Block (DCB), and the Driver 
Dispatch Table (DDT) 


e Unit Control Block (UCB) 

e Status Control Block (SCB) 
@ Volume Control Block (VCB) 
e I/0 packet 


When you write an ACP, you are uSually concerned only with the I/O 
packet, the DCB, the UCB, and the _ SCB. There are ACP-specific 
additions to and variations in the I/O packet, the DCB, and the UCB. 
The SCB is the same as that for an I/O driver. 


D.5.1 The I/O Packet 


Figure D-2 shows the layout of the 18-word I/0 packet, which is 
constructed by QIO$ directive processing. The fields in the I/0 
packet are described in detail in Section 4.1.1 of this manual. The 
following additions and variations exist for ACPs: 


I.FCN 


Contains the function code for the I/O request. The function 
code and modifier comprise a 16-bit field. Bits 13,14, and 15 
are reserved for ACP interface use. You must not assume that 
these bits are zero. 
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If the function code field is referenced, the value should be 
masked with 160000(8) for example: 


MOV I.FCN(R1),RO ; GET FUNCTION CODE FIELD 
BIC #160000, RO ; CLEAR OFF EXTRANEOUS BITS 


Aithough these bits are not currently in use, they should not be 
assumed to be zero in order to ensure future compatibility. If 
an I/O packet is requeued to the device driver, these bits must 
be cleared. 


I. PRM 


Contains the device-dependent parameters constructed from the 
last six words in the DPB. 


The following fields are defined for Files-ll nontransfer 
operations: 


-ASECT 

-=I.PRM 

I.FIDP: .~BLKW 2 File ID address (Address double 
word format) 

Attribute block pointer (This field 
points to a buffer containing the 
attribute list and associated address 
doublewords) 

Extend control from parameter list 
Retrieval pointers desired 

Access control 

File name block pointer 


I.RWAT: .~BLKW 1 


I. EXTD: .~BLKW 
I.RTRV: .BLKB 
I.ACTL: .BLKB 
I.FNBP: .~BLKW 


NF FD 


me “eo 6 NO MO MEA NS ME MO NE 


The following fields are defined for Files-1l transfer operations: 


~ASECT 
-=I.PRM 


I. RWAD: .BLKW 2 ; Transfer address doubleword 
I.RWCT: .~BLKW A ; Transfer count 
- BLKW 1 ; Unused 
I.RWVB .BLKW dl. ; Virtual block number 
- BLKW A ; Unused 
1 ; 


I.LCKB: .BLKW Address of lock block 
The above fields are set up by routines in the Executive. 


Only I.LCKB is referenced by SIOFIN; it must be either 0 or 
greater than 140000. 
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LLEFN, |.PRI EFN 
1.TCB TCB address of requestor 
IL.LN2 Address of second LUT word 
1.UCB Address of redirect UCB 
|.FCN Modifier 
1.1OSB Virtual address of I/O status block 
_ Relocation bias of I/O status block 
Real address of !/O status block 
|.AST | Virtual address of AST service routine 
1.PRM 
Device 
parameters 
ZK-228-81 
Figure D-2 I/0 Packet 


D.5.2 The DCB 


The DCB is described 
following additional 


D.MSK 
In general, I/0 


the ACP; all 
calls SGTPKT. 


in detail in Section 4.1.2 of this manual. The 
information applies to ACPs: 
requests marked as ACP functions are passed _ to 


others are passed to the device driver when it 


D.5.3 The UCB 

The UCB is described in detail in Section 4.1.4 of this manual. The 

following additional information applies to ACPs: 

U.CTL 

UC.QUE - Queue bypass bit . 

If UC.QUE is set, all I/O requests are passed to the 
driver without being queued first, regardless of any 
ACP-related processing in DRQIO. A driver that makes 
use of this option may alter the behavior of the file 
system, Since some functions are normally passed 


dGirectiy to the ACP, bypassing the driver queue. 


U.STS 


U.CW1l 


UC. KIL - 


US .MNT 


US.FOR 


US.MDM 
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If UC.QUE and US.FOR are set, all DIGITAL-specific ACP 
processing is bypassed. In this case, the driver must 
do all address checking and relocation. 


The UC.QUE option allows user-written ACPs to validate 
the ACP function parameters. Each I/O driver supported 
by the user-written ACP must contain code to do_ the 
validation. The validation must be done at this point 
in the I/O processing, because the routines that do 
address checking and relocation assume that the memory 
Management registers are in use by the tasks issuing the 
I/o. (Refer to the DRQIO module for examples of the 
techniques used to validate and save parameters.) 


Unconditional cancel I/0 call bit 


If UC. KIL is set, the I/O driver is called on a cancel 
I/O request even if the unit specified is not busy. 


Since ACP functions are dependent on sequencing, this 
function is normally turned into a no-op. 


An IO.KIL request has no effect on a mounted unit’ since 
the I/O queue is not flushed on the IO.KIL request when 
the DV.MNT (mountable) and US.MNT (mounted) bits are set 
for the unit. 


If US.MNT is set, the unit is not mounted. US.MNT is 
cleared when the volume is mounted. 


If US.FOR is set, the volume is mounted as_ foreign. 
US.FOR is set when the volume is mounted. 


If US.MDM is set, the volume is marked for dismount. 


An ACP normally checks the US.MDM bit when it processes 
a new I/O request. The ACP refuses operations that 
create a channel for processing (Such as OPEN) when 
US.MDM is’ set. After operations that terminate a 
channel (such as CLOSE), the ACP checks the current 
count of active channels to see if all ACP-related 
processing has been completed. If it is, the ACP 
completes the dismount. 


US.MDM is set when the volume is to be dismounted. 


This characteristics word is returned to the user task by the 
GLUN$ directive. U.CW1 is checked during validation of I/0 


request. 


DV. MNT 


The following bits are important to ACPs: 


If DV.MNT is set, the device is mountable. If a device 
is mountable, ACP functions can only be performed when 
it is mounted. 
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DV.F11 
If DV.Fll is set, the device is a Files-1l device. 
DV.F1l is set for both disks and tapes. If the device 
is Files-ll, the DV.SOQD bit determines whether’ the 
device is random or sequential. 

DV. COM 
If DV.COM is set, the device is mountable as a 
communications channel. This is used for DECnet. 

DV. SQD 
If DV.SQD is set, the device is sequential. If DV.SOD 
is reset, the device is random access. 

DV.SDI 
If DV.SDI is set, the device supports only aé_ single 
directory. 

DV.DIR 


If DV.DIR is set, the device is a directory device. 


D.6 AN EXAMPLE OF AN ACP-I/0O DRIVER COMBINATION 

The following is an example of an ACP, including a special driver used 
by the ACP. This ACP, supplied for demonstration purposes only, 
sounts the number of QIOs to a terminal. 


The modules supplied and their respective functions are: 


QDPRE.MAC - Prefix file for assembly 

QDDAT.MAC - Driver database 

QDDRV.MAC - Driver for ACP 

QDACP.MAC - The ACP itself 

QDCON.MAC -—- The task for enabling and disabling the ACP 


Example D-1 An ACP-I/O Driver Combination 
TITLE QDPRE 
-IDENT /01/ 
-ENABL LC 
This structure is purely for purposes of example. It is not intended 


be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


me Me “™S Ne Se 


to 
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**—QDPRE-QD: driver prefix file 


EXECUTIVE DEPENDENCIES 


The following is a list of the recognized Executive dependencies for the 
the QD: driver. If the implementation or functionality of the following 
features change, this driver and ACP may not function properly. 


1. The Executive I/O processing as described in RSX-11M Guide to Writing an I/0 
Driver remains unchanged. 


2. The following Executive routines remain unchanged: 
SSWSTK (SWSTKS) 
SBLXIO 
SEXRQP 
All of the routines documented in the RSX-11M Guide to Writing an I/0 Driver 


me Me Me Me Ne Ne Ne |s« me Me Me Me Ne te Ne Se Se te NO 


System Macro Calls 


me ™e SO 


-MCALL UCBDFS$ 
UCBDF$ 


QD driver-specific offsets 


=e es SO 


~ASECT 
- =U. VCB+2 ; End of UCB 
U.QACP::.BLRKW 1 3; Address of QD ACP TCB 
U.QCTL::.BLKW 1 : ACP control and status word 
U. QOLUN::.BLKW 1 ; LUN used by ACP when doing I/0 for this unit 
U.QTRN::.BLKW q ; Count of transactions outstanding to ACP 
UQ. STP==100000 ; Stop requested for ACP on this unit 
UQ. ONL==40000 ; This unit online 
-PSECT 
Q$$D11=3 ; Number of units 


LDSQD=0 Driver loadable 


“eo 


TITLE QDDAT 
.IDENT /01/ 


~-ENABL LC 


me “NO NO NO TO 


=o ™e TO MO NA NO NO Ne NO 


SQDDAT:: 


QDDCB: 


ue NO TO NS We 


$$$=0 


QDST=. 
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This structure is purely for purposes of example. It is not intended to 
be useful nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


**-QDDAT-OD: driver device tables 


The following data structure is designed with two things in mind: 


1. Providing the minimum structures to look like a disk 
2. Providing the minimum structures to satisfy the Executive 
and the MCR LOA commands. 


-WORD 
-WORD 
-ASCII 
~BYTE 
- WORD 
~WORD 


-WORD 
-WORD 
- WORD 
~WORD 
-WORD 
- WORD 
-WORD 
-WORD 
-WORD 


-NLIST 
~ LIST 


» REPT 


«LRP 


IF DF 


.- WORD 
-WORD 


- ENDC 


0 
- QD0 
/QD/ 


0,QS$D11-1 


QODND-QDST 
0 


TITO3-7 
000030 
000000 
177000 
000777 
000000 
000000 
000777 
0 


MD 
ME 


Q$$D11 
XX,\<SS$> 


MSSMUP 


oo 


~ 


™~me 


me me Ne Ne TO 


me me SO SO we Oe Ne MO MO 


a 


Start of QDDRV device tables 


Link to next DCB 

Pointer to first UCB’ 

Device name 

Lowest and highest unit number  ! 

Length of UCB | 

Pointer to driver dispatch table, set by LOA 


The following table defines the initial processing of I/O functions in the 
Executive QIO directive processing. The legal functions selected are those 
of the standard disk drivers. 


Legal functions 0.-15. 

Control functions 0.-15. 

No-op functions 0.-15. 

ACP functions 0.-15. 

Legal functions 16.-3l. 

Control functions 16.-31. 

No-op functions 16.-31. 

ACP functions 16.-3l. 

PCB address of driver partition 


Start of UCB 


Login UIC, multi-user protection system 
Owning terminal UCB address 
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-QD'XX': .WORD QDDCB 
-WORD - QD 'XX 
-BYTE UC. PWFIUC.ALG!3 


Back pointer to DCB 

Redirect pointer 

Control flags byte, call on powerfail 

to allow proper setting of on-line/off-line bit 
~BYTE US.MNT Status byte 

~ BYTE 0 Physical unit number, does not apply 
BYTE 0 ; Second status word 

»~WORD DV.MNT!IDV.F11!DV.SDI!IDV.DIR ; Characteristic word 1 
-WORD 0 Characteristic word 2, size of device 
-WORD 0 Characteristic word 3 

~WORD 512. Characteristic word 4, buffer size 
~WORD $QDO Pointer to SCB 


eo "8 ue Me Ne MO NO 


’ 
7 
~WORD 0 3 Attached task TCB address 
« BLKwW 2 ; User buffer pointer 
- BLKW 1 7 and byte count 
»WORD 0 ; Address of file system ACP TCB 
~WORD 0 ; Address of VCB for file system 
»WORD 0 ; U.QACP-QDACP TCB address 
»WORD 0 ; U.QCTL-QDACP Control word 
WORD "X¥X'4+1 ; U.QLUN-QDACP LUN for I/0 
QDND=,. ; End of UCB 
- ENDR 
$$$=S$$+1 
« ENDR 
-NLIST ME 
LIST MD 
$QD0:: .WORD 0,.-2 ; Device I/O queue 
~BYTE 0,0 ; Device priority and vector 
~BYTE 0,0 ; Current and initial device timeout count 
-BYTE 0,0 3; Controller index and device status 
-WORD 0 ; CSR address 
~WORD 0 ; Address of I/O packet 
»~BLKW 5 ; Fork block 
SQDEND:: ; End of QDDRV device tables 
. END 


-TITLE QDDRV 
IDENT /01/ 


~ENABL LC 
This driver is purely for purposes of example. It is not intended to 


be a useful driver nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


me Se te we te 


**-QDDRV-QOD: driver 


me me Ne te 


me te NO 


me Ne Ne 


SQDTBL::.WORD QDINI 


=e Me Ne 


ACPTNM: .~RAD50 /QDACP / 


~e “Oe Se Me Me Me NO Me MO MO Me NO WO MO Ne Me We Me Se NE Ne NE 
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MACRO LIBRARY CALLS 


DRIVER DISPATCH TABLE 


Initiator entry point 
Cancel I/O entry point 
Device timeout entry point 
Powerfail entry point 


-WORD QDCAN 
-WORD QDOUT 
-WORD QD PWF 


we "tO NO Ne 


LOCAL DATA 


IF DF AUTOST 


Default ACP task name 


=e 


- ENDC 


**-QDINI - "Disk" Driver 


This driver, in conjunction with its Ancillary Control Processor (ACP) 
appears to be a disk, but its operational characteristics are 

unusual. The actual storage medium may be any of a number of devices 
including memory, disk, or DECnet link. No driver queue is maintained; 
all I/O packets are queued directly to the ACP. The cancel I/0, device 
timeout, and powerfail entry points are all-set to be no-ops. The actual 
processing of the request is left to the ACP. 


Remember, this driver is an example and demonstrates multiple features 
of the driver/ACP/Executive interface. 


Inputs: 
R5=UCB address 


The buffer address and count for IO.RLB and IO.WLB have been validated 

by DROIO processing code. I0.KIL, IO.ATT, and IO.DET are processed by 

the Executive's standard I/O processing routines. I0.CTL is queued directly 
to QDACP. 


-ENABL LSB 


QDINI: ; Driver initiation entry point 
CALL SGT PKT ; Get I/O packet 
BCS EXIT ; If CS none to get 
CLRB S.STS (R4) ; Unbusy controller since ACP does all work 
MOV R1,R3 ; Copy I/O packet address 
BIT #UQ.ONL,U.QCTL(R5) ; Unit online? 
BEQ 20$ ; If EQ no 
MOVB I.FCN+1(R3),RO ; Get function code 
CMPB #I10.RLB/400,RO ; Read logical block? 
BEQ QOPRLB ; If EQ yes 
CMPB #IO.WLB/400,RO ; Write logical block? 
BNE ERRIFC ; If NE no 


me we te TO tO NO 


Function specific validation routines. 
be made later in the ACP, but they are easily made here and have 
the added benefit of saving of two context switches (to and from 
the ACP) to return an error. 
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The checks here could 


QPWLB: MOV #IE.WLK&377,RO ; Assume write locked 
BIT #DV.SWL,U.CW1(R5) ; Unit software write locked? 
BNE IOFIN ; If NE yes 
; Join common code 
QPRLB: CALL SBLKCK ; Check for valid logical blocks 
MOV R3,Rl1l ; Restore the I/O packet address to Rl 
MOV U.QACP(R5),R0 ; Get address of ACP's TCB. The offset U.ACP 
; can NOT be used since file system ACP uses 
; that location. The UCB is used for TCB 
; because it is easy for the ACP to access 
; (aS opposed to some location within the 
; driver). 
BNE 10$ ; If NE the ACP has been started. 
; The next few lines of code may be used as 
; an alternate method of starting the ACP. 
; They allow the ACP to be started 
; automatically if it is installed. 
; They can't be used in this application 
: since ACP needs some initialization info 
-IF DF AUTOST ; If defined, auto start ACP 
MOV #ACPTNM,R3 : Get address of ACP task name 
CALL SSRSTD : See if our ACP is installed 
BCS 20S : If CS no 
BIT #T3.ACP,T.ST3(RO) ; Built as an ACP? 
BEQ 20S ; If EQ no 
MOV RO,U. QACP(R5) : Save address of ACP 
. ENDC 
10S: INC U.QOTRN(R5) ; Increment count of transactions in ACP queue 
JMP SEXRQP ; Queue to the ACP by priority and activate 
; it. This request will unstop the ACP if 
; is stopped or run it if its not active. 
208: :; Reference label 
MOV #IE.OFL&377,RO ; I/O status of device not ready 
BR IOFIN ; Finish I/O request 
ERRIFC: MOV #IE.IFC&377,RO ; I/O status of illegal function code 
; Finish I/O request 
IOFIN: CLR Rl ; Second I/O status word 
JMP SIOFIN ; Finish I/O request 


-DSABL LSB 
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**-~QDPWF-Powerfail, Mark offline units offline 


me me Oe 


QDPWF: BIT #UQ.ONL, OCTL(R5) ; Unit offline? 
BNE 10$ ; If NE no 
BISB #US.OFL,U.S:i2(R5) ; Set offline 
108: ; Reference label 


**-QDCAN-Cancel I/O in progress, ignored 
**-QDOUT-Device timeout, does not apply 


me M8 Ne TO 


ODCAN: 

QDOUT: 

EXIT: RETURN 
- END 
~-TITLE QDACP 
-IDENT /01/ 
~-ENABL LC 


me te NO NO MO 


**-QDACP-OD: driver ACP 


we te NO WO 


MACRO LIBRARY CALLS 


me te Ne 


»MCALL 


LOCAL DATA 


=e “we “Oe 


-QIO:: QIOs 


-lOST:: .BLKwW 2 
- LOPKT::.BLRKW 1 
-ACTUN: : WORD 0 
WTSE: WTSES 1 
IOSB: - BLKW 2 
FID: - BLKW 3 


° 
‘ 


This ACP is purely for purposes of example. 
be a useful ACP nor is it supported in any way. 
functional, complete, and representative of a valid interface. 


“=e me ‘NO 


These functions are no-ops 


It is not intended to 
It is, however, 


ALUNSS , DIRS, QIO$,WTSES,WSIGSS 


,1,1,,IOSBy-<r7777> 7 MY own QIO DPB 


I/O status to return to user 
Address of current I/O packet 
Count of active units 

Wait for I/O completion 

I/O status block for my I/0 


File ID of work file 


me Ne tO 


**-, START-ACP 


START: :CALL 


me me Ne 


**—. GTPKT-Get 


~GTPKT::CLR 


me me me we NO 


40S: 


SWSTKS 


MOV 


ADD 
CALL 
BCC 
TST 
BNE 
MOV 
JMP 


JMP 


MOV 
RETURN 


MOV 
BEQ 


MOV 


MOV 
CLR 
MOV 
MOV 
CLR 
DEC 
BNE 
MOV 
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Starting entry point 


- INIT 


’ 


Do one-time initialization 


the next I/O packet from ACP queue and dispatch function 


. IOPKT 
30$ 


STKTCB,RO 


#T..RCVL, RO 
SQRMVF 

20$ 

. ACTUN 

10$ 
STKTCB,R5 
SDREXT 


SSTPCT 


R1l,.IOPKT 


- IOPRT, R3 
» GT PRT 


I.UCB(R3),R5 


Process I/O request 


Do any initialization required 


#IS.SUC,.IOST 


. IOST+2 


#.Q10+0. IOPL, RO 


#6,R1 
(RO)+ 
Rl 
40$ 


me me “GO me Ne Ne Se NO Me Ne 


me we we NO Ne me MO He MO Ne NO we SO Me MO A we MO NO me TO Ne 


me TO Me we NO Ne 


¢ 


me Ne SO we NO Ne He ME NO NO Ne Me Se Ne NO SO Me NO NS Ne Se Ne TO Be Be Be WE 


No I/0 packet yet 
Switch to system state to synchronize with 
Executive. This prevents context switching 
and makes Executive routines accessable. 
On return from system state, execution will 
resume at 30$. This call also saves all 
registers. 

Address of my TCB (must be my TCB since 
can't execute in context of any other task 
Point to receive queue listhead 

Attempt to dequeue I/O packet from queue 
If CC I/O packet removed from queue 
Is this ACP still active for any units? 
If NE yes 

R5 must be our TCB address 

No I/O requests in our queue and no active 
units, perform a task exit without any 
possibility of a race between QDCON 
inserting an I/O request in our queue 
and our task exit. 
Stop current task (us) and return to task 
state. Once back in task state the PC will 
be at 30S, since once we are unstopped we will 
resume execution at 30$, not the next line. 
Save I/O packet address. (Return to task 
state restores all registers.) 
Return to task state. Complementary to 
SWSTKS. 

Get I/O packet address 

If EQ none found in queue, try again since 

someone unstopped us. 

Get UCB address for request 


Initial status of success 

Point to parameter list are of our QIO DPB 
Number of words to clear 

Clear them 

Done? 

If NE no 


U.QLUN(R5),.QI0+Q0.IOLU ; Setup LUN in DPB 


me ™e “Oe we SNe “O Ne Ne BSH NO 


1008S: 


1108: 


me Be TO 


IEIFC: 


~e Oe we NO SE Me Me 


- IOFIN: 


10S: 


208: 


20S: 
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Dispatch function 


I/O function is dispatched with the following registers 


R5=UCB Address 
R3=I/0 Packet 


MOVB 
CMPB 
BNE 
IMP 
CMPB 
BNE 
JMP 
CMPB 
BEQ 


MOV 


INPUTS: 


And .QI0O has the correct LUN plugged into the DPB 


I. FCN+1 (R3) ,RO Get I/O function code 


#IO0.RLB/400,RO ; Read logical block? 
100$ ; If NE no 

FCRLB ; Process read 
#I10.WLB/400,RO ; Write logical block? 
110$ ; If NE no 

FCWLB ; Process write 
#IO.CTL/400,RO ; ACP control function? 
FCCTL ; If EQ yes 


Illegal function code 


#IE.IFC&377,.1I0ST ; I/O status of illegal function code 


**-, TOFIN-Finish I/O request returning status to user. 


-IOST=I/O status of current request 
- IOPKT=Address of I/0 packet 


MOV 
MOV 
MOV 
MOV 
SWSTKS 
CLR 
DEC 


BNE 
BIT 


BEQ 
BITB 
BEQ 
TST 
BNE 
BIC 


BISB 
CLR 
INC 
JMP 


ASR 
BCC 
CALL 
DEC 
JMP 


- LOST, RO Get I/O status 


this unit been received? 


’ 

- LOST4+2,R1 ee 

- LOPKT,R3 3; Get address of I/O packet 

I.UCB(R3),R5 ; Get UCB address 

20$ 7; Switch to system state 

- IOPKT 77 No I/O packet anymore 

U. QOTRN(R5) 7; Decrement count of outstanding I/O queued 

737 to ACP 

10$ 77 If NE more requests in queue 

#UQ.STP,U.QCTL(R5) ;; Has a request to stop processing on 
ae 

10$ :; If EQ no 

#US.MNT,U.STS(R5) ;; Unit still mounted? 

10$ 3; If EQ yes 

U.ATT (R5) +; Unit attached? 

10$ 3; If NE yes 


#UQ. STP!UQ.ONL,U.QCTL(R5) ; Clear our on-line bit and stop 
37 request flag 
#US.OFL,U.ST2(R5) ;; Mark unit offline 


U. QACP (R5) 7; No ACP active on unit 

- IOPKT 77 Flag to indicate unit went to off-line state 
SIOFIN 3; Finish I/O request and return to task state 
- IOPKT ; Unit go to offline state? 

30$ 3; If CC no 

» CLOSE ; Close up shop on this unit 

. ACTUN ; Decrement count of active units 

- GTPKT 7; Get next I/O request 


me Me We Me Me MO Me Ne TE Te ME MO TO TE Te Te WS Ws We Ne Te we DS 


-DOIO: SWSTKS 10S 


me Se NOR Ne NE 


™e we te Me 


me TO Ne te 
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**k*-,DOIO-Do I/O for user to real device 


This routine maps to the users buffer(s) and issues an I/O request that 

will use the requesting task's buffers. This occurs because the QIO 

processing uses the logical mapping, not the virtual mapping, to determine 

where buffers are located. By logical mapping, I mean the physical mapping 
contained in the memory management registers. Because we are privileged, 

no validity checking is made on the buffers, so it is possible to do I/0 

to buffers larger than the windows through which they are mapped, that is, greater 
than about 4KB. This routine will function properly if the ACP overmaps 

the I/0 page because it switches to the system stack, hence to kernel mode. 
Therefore, this routine must not be mapped by APR 7. 


INPUTS: 
RO=Buffer 1 mapping for user APR 1 
Rl=Buffer 2 mapping for user APR 2 


OUTPUTS: 
I/O issued and completed 
If cc then IOSB is I/O status 
If CS then $DSW is directive error 


Switch to system state 


cd 
MOV UISARO+2,2(SP) ; Save user APR 1 value in saved RO 
MOV UISARO+4,4(SP) ; And user APR 2 value in saved Rl 
MOV RO, UISAR0+2 7 Map to user's first buffer 
MOV R1, UISARO+4 ; Map to user's second buffer 
INCB SCXDBL ; Disable context switching 
RETURN ; Return to task state 

td 


Reference label 


Issue the QIO directive, context switching is disabled so we don't have 
to worry about user APRs 1 and 2 being modified. However, we can't wait 
for the I/O to complete at this point. 


DIRS #.Q10 3; Issue I/O request 
ROR -(SP) ; Save carry state 


Buffers have been "validated" and relocated so we can restore original 
mapping and enable context switching. 


SWSTKS 20S Switch to system state 


‘ 
MOV RO, UISARO+2 3; Restore user APR 1 
MOV R1, UISARO+4 ; Restore user APR 2 
DECB SCXDBL ; Enable context switching 
RETURN ; Return to user state 
, 


Reference label 


Context switching is now enabled, check directive status and if successful 
wait for completion 


ROL (SP)+ ; Restore carry, was directive successful? 
BCS 30$ ; If CS no 
DIRS #WTSE ; Wait for I/O to complete 

30S: RETURN ; Return to caller 


D-20 
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-BLXI: 


me “™e Se M2 Ne WO Me NO Me HS MS TE 


-BLXO: 
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INPUTS: 


RO=Byte count to transfer 
Rl=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 


OUTPUTS: 


Data in our buffer 


-ENABL LSB 


SWSTKS 205 ; 
MOV RO,R5 : 
MOV R1,-(SP) : 
MOV R2,-(SP) ; 
MOV R3,R0 F 
CALL SRELOC ; 
MOV R1,R3 : 
MOV R2,R4 : 
MOV (SP)+,R2 : 
MOV (SP)+,Rl ; 
BR 10$ ; 


INPUTS: 


RO=Byte count to transfer 
Ri=Address mapping base 
R2=APR 6 displacement 
R3=Address of our buffer 


OUTPUTS: 


Data in user buffer 


SWSTKS 20S : 
MOV RO,R5 : 
MOV R3,RO0 ; 
MOV R1,R3 ; 
MOV R2,R4 : 
CALL SRELOC : 
MOV R5, RO : 
ADD #120000-140000,R2 
JMP SBLXIO : 
RETURN ; 
-DSABL LSB 


*xkx-—,.BLXI-Transfer data into our buffer 


Switch to system state 

Save R5 

Save Rl 

And R2 

Set virtual address of our buffer 
Convert to address double word 
Copy Rl and 

R2 to proper place for $BLXIO 
Restore R2 

and Rl 

Join common code 


**x-,.BLXO-Transfer out of our buffer into user's buffer 


Switch to system state 

Save RO 

Set RO to address of our buffer for SRELOC 
Copy Rl and 

R2 into proper place for $BLXIO 

Convert to address doubleword 

Restore byte count 

; Convert to APR 5 displacement 

Transfer data and return to task state 
Return to caller 
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**-FCCTL-ACP control functions 
Two control functions are supported, start-up and shut-down. 


We check the request for validity and then set up various fields in the 
drivers UCB. 


me TE MO MO NS MO NS TE 


FCCTL: MOV I.TCB(R3),R0 ; Get TCB address of issuing task 
BIT #T3.PRV,T.ST3(RO) ; Task privileged? 
BEQ IEIFC : If EQ no 
CMPB #1,1.FCN(R3) ; Startup request? 
BEQ 10$ ; If EQ yes 
CMPB #2,1.FCN(R3) ; Stop request? 
BEQ 30$ ; If EQ yes 
BR IEIFC ; Illegal function 


+ Process start request 


10$: TST U. QACP (R5) ; Already got an ACP? 
BNE 20$ ; If NE yes 
CALL .- OPEN ; Open up shop for unit 
BCS 100$ :; If CS failed to open channel to "device" 
INC - ACTUN : Increment count of units active 
MOV STKTCB,U.QACP(R5) ; Set ACP TCB address in UCB 
BIS #UQ.ONL,U.QCTL(R5) ; Set unit online 
BICB #US.OFL,U.ST2(R5) ; And for the operating system 
BR 100$ : Join common code 
208: MOV #IE.RSU&377,.1IO0ST ; ACP already started for unit error 
BR 100$ ; Join common code 


; Process stop request 


308: CMP STKTCB,U.QACP(R5) ; Unit online with correct ACP? 
BNE 50$ >: If NE no 
BIT #UQ.STP,U.QCTL(R5) ; Stop requested? 
BNE 60$ ; If NE yes 
CALL SSWSTK,100$ 7:7; Go to system state to prevent a race problem 
BITB #US.MNT,U.STS(R5) 3; Unit still mounted? 
BEQ 40$ 3 If EQ yes 
TST U. ATT (R5) 37 Unit attached? 
BNE 40S 7; If NE yes 
CMP #1,U.QTRN(R5) :; Is this this the only transaction queued? 
BNE 40$ 7; If NE no 
BISB #US.OFL,U.ST2(R5) 3; Mark unit off line to prevent further I/0 
BIS #UQ.STP,U.QCTL(R5) ;; Request unit be stopped 
RETURN ::; Return to task state at statement 100$ 
40S: MOV #IE.NFW&377,.IOST ;; Unit busy, attached, or mounted 
RETURN ;; Return to task state at statement 100$ 
50S: MOV #IE.OFL&377,-10ST ; Unit offline 
BR 1005S ; Join common code 
60S: MOV #IE.FLN&377,-IOST ; Already being stopped; error 
1008S: JMP . IOFIN ; Finish I/O request 


sme “Me Me Ne MH Ne We We We WO 


=e ™e Te 


. ENABL 


FCRLB: CALL 
BCS 
MOV 
MOV 
MOV 
MOV 
MOV 
CALL 
BR 


=e Se Ne 


FCWLB: CALL 
BCS 
MOV 
MOV 
MOV 
MOV 
CALL 
MOV 


me Oe NO 


10S: MOV 
MOV 
SUB 
MOV 


CALL 
BCC 
MOV 
BR 
20S: MOV 
MOV 
30S: JMP 


- DSABL 
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WARNING 


LSB 


. READ 

10$ 

I. PRM+4 (R3) ,RO 
RO, - 1OST+2 

I. PRM(R3),R1 
I. PRM+2 (R3) ,R2 
R4,R3 

. BLXO 

30$ 
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»-WRITE ; 
Les i 
I.PRM+4(R3),RO ; 
I. PRM(R3),R1 : 
I.PRM+2(R3),R2 ; 
R4,R3 : 
« BLXI 7 
- LOPKT, R3 ; 


Do I/O from user buffer 


I.PRM(R3),RO ; 
I.PRM+2(R3),Rl_ ; 
#140000-20000,R1 
R1,.Q10+0. IOPL 


- DOIO 
20S 
#IE.AB0&377,.IOST 
30$ ; 
IOSB,.IOST ; 
; 
c 


se Ne we te 


IOSB+2, .1OST+2 
- IOFIN 


LSB 


° 
s 


The above code must be in the first 8K of the ACP because 

a Switch to system state uses the kernel mode mapping which 
allows only 8K for task mapping. (The I/O page is mapped in 
thru APR 7 in system state, but may be overlaid by the task 
in task state.) 


**-FCRLB-Read logical block function 


Data in memory already? 

If CS no 

Get byte count 

Set return status byte count 
APR mapping 

APR6 displacement 

Address of our buffer 
Transfer to user buffer 

Join common exit code 


**-FCWLB-Write logical block function 


: Transfer data to our buffer first? 


If CS no 


; Get byte count 


APR mapping 

APR6 displacement 

Address of our buffer 
Transfer to our buffer 
Restore I/O packet address 


Get mapping value for APR 1 
Get displacement biased for APR6 
Adjust to an APR1 bias 
Insert virtual address of buffer when mapped 
‘via APR 1 
Issue I/O request 
If CC successful 
; Return error to user 
Join common code 
Return status to user 


eee 


Finish I/O request and dispatch next request 


-_me we Me 


~ INIT: 
RETURN 


Inputs: 
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~OPEN: ALUNSS 
BCS 
MOV 
MOV 
MOV 
MOV 
CALL 
MOVB 
BMI 
CLR 
CLR 
MOV 
MOV 
CALL 
MOVB 
BMI 
CLR 
MOV 
CALL 
MOV 
RETURN 

10S: SEC 
RETURN 


208: CRASH 


me “ee we 


~-CLOSE: MOV 
MOV 
10$: CLR 
DEC 
BNE 
MOV 
JMP 


Inputs: 


 ™e we ee “OH BS WO 


USER-WRITTEN ANCILLARY CONTROL PROCESSORS 


**-, INIT-One time initializations on startup 


None 


=e “Oe 


**-,OPEN-Open up I/0 path for unit 


R5=UCB address 
R3=I/0 packet address 


U.QLUN(R5),#"SY,#0 ; Assign LUN to work file device 

20S : If CS error 

#IO.CRE,.QIO+Q.IOFN ; Setup for create file 
#FID,.QIO+Q.IOPL ; Insert address to receive file ID 
#100000, .QI10+Q.IOPL+4 ; Enable extend 

I. PRM(R3),-.-QIO+Q.IOPL+6 ; Allocate file of size requested 


XIO Create and extend file 
IOSB,.IOST Copy I/O status 
10$ If MI error 


- Q10+Q. IOPL+4 Reset parameter 

- QT0+0. IOPL+6 Ditto 

#10.ACW,.QIO+Q.IOFN ; Set up to access the file 
#100000, .Q10+0.IOPL+10 ; Enable access 


me Ne OO me MO 


XIO ; Access file 
IOSB,.IOST ; Copy I/O status 
10$ : If MI error 


~QIO+Q.IOPL+10 ; Reset parameter 
#10.DEL,.QIO+Q.IOFN ; Set up to mark file for delete 
XIO ; Mark file for delete 
I.PRM(R3),U.CW3(R5) ; Set up device size 

; Successful exit with carry clear 
; Error exit with carry set 


; Internal error 


*k—~.,CLOSE-Close channel to device 


#6,R0 ; Number of parameters to clear 
#.QI0+Q.IOPL,R1 ; Address of parameter list 
(R1)+ ; Reset parameters 

RO ; Done? 

10$ ; If NE no 

#1T0.DAC,.QIO+Q.IOFN ; Set to deaccess file 

XIO ; Deaccess file 


**k*-,READ-—Determine method of performing read 


R5=UCB Address 
R3=1/0 Packet 


me me SA MO we BO TO 


- READ: 
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Outputs: 
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If CS then do I/O directly into user buffer 

-QI10 DPB setup with I/0 function code 

If CC then do I/O to our buffer, then copy to user buffer 
R4=Address of buffer 


*kx-—,WRITE-Determine method of 


Inputs: 


#I10.RVB,.QIO+OQ.IOFN ; Set up to read 

I. PRM+4 (R3),.-QIO+Q.IOPL+2 ; Insert byte count into DPB 

I. PRM+10(R3),.QI10+0.IOPL+6 ; And block number to Start transfer 
I. PRM+12(R3),.-QIO+O.IOPL+10 ; 


#1,.QI0+0. IOPL+10 
.Q10+0. IOPL+6 
#1000,1.PRM+4 (R3 
10$ 

#.BUF,R4 
R4,.Q10+0. IOPL 
XIO 

IOSB 

10$ 
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R5=UCB Address 
R3=I1/0 Packet 


Outputs: 


+ Convert from "logical" to "virtual" 


rh 
th 
oO 
ry 
7" 
md 
% 
n 
+ 
$v) 


3 Do I/O to our bu 
If NE no 

Set address of buffer 

Set up buffer address 

Read data into our buffer 

On error go directly to user buffer; error? 
If MI yes 

Copy to user buffer 


aeeewue 


Do I/O directly to user buffer 


performing write 


T£ CS then do I/O directly from user buffer 

-QI1IO DPB setup with I/0 function code 

If CC then copy data to our buffer, then do I/O from user buffer 
R4=Address of buffer 


eWRITE: MOV 


10S: 


#10.WVB,.QIO+Q.IOFN ; Set up to write 

I. PRM+4 (R3),-QIO0+Q.IOPL+2 ; Insert byte count into DPB 
I. PRM+10(R3),.QIO+Q.IOPL+6 ; And block number on device 
I. PRM+12(R3),-QI10+0.IOPL+10 ; 


#1,.QI10+0. IOPL+10 
.QIO+Q.IOPL+6 ; 
#1000, 1. PRM+4 (R3) 
10$ 

#. BUF, R4 


ue MO Me Ne MO MO 


; Convert from "logical" to "virtual" 


; Copy to our buffer first? 
If NE no 

Address of buffer for data 
Copy from user buffer 


Do I/O directly from user buffer 
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**-XIO-Execute QIO request 


=e ee SO 


XIO: DIRS #.QI0 ; Issue I/O request. 
BCC 10$ ; If CC successfully issued 
CMP #IE.UPN, SDSW ; No dynamic storage available? 
BNE 20$ 3; If NE no 
WSIGSS ; Hope 
BR XIO ; «eehope 

108: DIRS #WTSE ; Wait for I/O to complete 
BCS 20S ; If CS error 
RETURN : 

208: CRASH ; Internal error 

7 

; I/O buffer 

rd 


. BUF: .- BLKB 1000 One block long 


=e 


- END - START 


.TITLE QDCON 
IDENT /01/ 


-ENABL LC 
This control task is purely for purposes of example. It is not intended to 


be a useful task nor is it supported in any way. It is, however, 
functional, complete, and representative of a valid interface. 


me Se Ne we HO 


**-QDCON-QOD: driver and ACP control task 


me ™e “Se Ne 


MACRO LIBRARY CALLS 


we “Oe Ne 


-MCALL ALUNS$,GLUNS,DIRS$,GMCRS,WTSESS, QIOWSS, EXSTSS 
-MCALL ISTATS,STATES, TRANS 


DEFINE PARSER STATE TABLE 
The following commands are supported: 


>QDC START QDn:/SIZE:n 
where 
START is the subcommand to startup the ACP specifying the "disk size" 


>ODC STOP QDn: 
where 
STOP is the subcommand to stop the ACP at the earliest opportunity 


me nue S08 NO TH We MWS We Be Be Ne We We 
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ISTATS QDCSTB,QDCKTB 


Skip command name 


=e 


STATES INITL 
TRANS SSTRNG 


3; Determine subcommand 


STATES 
TRANS "START" ,START, , SSTART, SDISPT 
TRANS "STOP" ,STOP, ,SSTOP, SDISPT 


; Process START command, get device name 


STATES START 
TRANS !DEVICE 


STATES OPTION 
TRANS '/, SWITCH 
TRANS SEOS, SEXIT 


STATES SWITCH 


TRANS "SIZE",SIZE 
STATES SIZE 

TRANS '= 

STATES 


TRANS SNUMBR, OPTION, SETSIZ 
; Process STOP command 


STATES STOP 
TRANS IDEVICE 


STATES 
TRANS SEOS, SEXIT 


; Process device name 


STATES DEVICE 
TRANS  SALPHA,,SETDV1 


STATES 
TRANS SALPHA, , SETDV2 


STATES 
TRANS SNUMBR, DEV1,SETUNT 
TRANS SLAMDA 


STATES DEVI 
TRANS ';,SEXIT 


:; Terminate state table 


STATES 


=e tO Ne 


=e 


SETDV1: 
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PARSER ACTION ROUTINES 


Set first character of device 


MOVB . PCHAR, $SDEV 


RETURN 


=e ~e 


name 


Save first character of device name 


; Set second character of device name 


SETDV2: MOVB 


RETURN 


; Set device unit number 


SETUNT: 


; Set device size 


SETSIZ: 


LOCAL 


=e we NO 


ALUN: 
SDEV= 
SUNIT= 
GLUN: 
GLUBUF: 
SPDEV= 
SPUNIT= 
SCHAR= 
GMCR: 
SSIZE: 
SDISPT: 
AC PNAM: 
PRMLST: 


SIOST: 


Error 


Sy nt et 


- MACRO 


. ENDM 


- PCHAR, $DEV+1 ; 
; 


MOV - PNUMB, SUNIT ; 
RETURN ; 
MOV . PNUMB, SSIZE ; 
RETURN ? 
DATA 


ALUNS 1,, 
ALUN+A. LUNA 
ALUN+A. LUNU 


GLUNS$ 1,GLUBUF 


. BLKW 6 
GLUBUF+G. LUNA 
GLUBUF+4G. LUNU 
GLUBUF+G. LUCW 
GMCRS$ 

-WORD 0 
-WORD 0 


-RAD50 /QDACP / 


- BLKW 8. 
- BLKW 2 
messages 
ERM ERN, STS, 
» PSECT 
$$$l=. 
eASCITI 
$$$2=. 
- PSECT 
ERN: »~WORD 
-WORD 


me me Be MO me me Oe Me 


me 


=e 


~e 


=e 


TEXT 
SSERMG 


<15>"TEXT* 


STS 


Save second character 


Save converted unit number 


Save converted size 


Assign LUN to QDn: 

Address of device name 
Address of device unit number 
Get LUN information for QD: device 
LUN information buffer 

Actual device name 

Actual device unit 

Device characteristics word 
Get MCR command line 

Device size to create 

Address of service routine 
Name of ACP 

Parameter list for I/O packet 


I/O status 


$$$1,$8$2-S$$1 


- MACRO 


- ENDM 


«MACRO 


- ENDM 


«MACRO 


- ENDM 


ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 
ERM 


se "Oe MO 


SQDCON: 


10S: 


20S: 


3052 
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ERRX ERN 
MOV #ERN, RO 
JMP SERRXT 


FTLX ERN 
MOV #ERN, RO 
IMP SSUCXT 


SUCX ERN 
MOV #ERN, RO 
JMP $S UC XT 


ERRCML, 14,<%QDC-F-GETCOMFAIL, Failed to get command line> 
ERRSYN, 24,<%QDC-F-SYNERR, Syntax error in command> 

ERRNQD, 34,<%QDC-F-NOQDDEV, Failed to assign LUN to QD:> 

ERRBDV, 44,<%QDC-F-BADDEVICE, Invalid device specified> 

ERRNOD, 54,<%QDC-F-NOPOOL, No dynamic memory for I/O request> 
ERRNAC, 64,<%QDC-F-NOACP, QDACP not installed in system> 

ERRREQ, 74,<%QDC-F-REQFAIL, Failed to request QDACP> 

ERRUSE, 104,<%$QDC-F-DEVINUSE, Specified unit already in use> 
ERRINT,114,<%QDC-F-INTERNAL, Internal error> 

ERRFLN, 124,<%QDC-F-OFFLINREQ, Unit already requested to offline> 
ERRNOL, 134,<%$QDC-F-NOTONLINE, Unit not online> 

ERRNDS, 144,<%$QDC-F-NODISSPAC, Failed to allocate disk space> 
ERRBSY, 154,<$QDC-F-DEVICEBUSY, Device busy, mounted, or attached> 
ERRFTL,0,<-QDC-F-ONLFAIL, Failed to bring unit online> 

SUCCOM, 161,<%QDC-S-ONLINE, Specified unit brought online> 
REQOFF,171,<%QDC-S-REQOFFLINE, Unit requested to offline> 


**-,QDCON-QD device control program 


CLR SDISPT ; Reset service routine dispatch address 
CLR SUNIT : Clean out unit number 

DIRS #GMCR ; Get the command line 

BCC 10$ 3; If CC successful 

FTLX ERRCML 

CLR Rl ; Suppress blanks 

MOV #QDCKTB,R2 ; Get keyword table address 

MOV SDSW, R3 +; Get length of command line 

MOV #GMCR+G.MCRB,R4 ; Get address of command line 

MOV #INITL,RS5 ; Get address of initial parser state 
CALL - TPARS ; Parse command line 

BCC 20$ 7 If CC good command line 

FTLX ERRSYN 

DIRS #A LUN ; Assign LUN to QD: 

BCC 30$ ; If CC good device 

FTLX ERRNOQD 

DIRS #GLUN ; Get device information 

JMP @SDISPT ; Dispatch to START or STOP service 


me "€e GO 


SSTART: 


108: 


1108: 


1208: 


1308S: 


me Te Ne 


SSTOP: 


10S: 


1008: 


110S: 
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**k-SSTART-Start up ACP and 


CMP 
BEQ 
FTLX 


MOV 
MOV 
MOV 
MOV 


CALL 
BCC 
CMP 
BNE 
ERRX 
CMP 
BEQ 
CMP 
BNE 
ERRX 
ERRX 


CMPB 
BNE 
SUCX 


CMPB 
BNE 

ERRX 
CMPB 
BNE 

ERRX 
FTLX 


**-SSTOP-Stop 


CMP 
BEQ 
FTLX 


MOV 
MOV 
MOV 


CALL 
BCC 
CMP 
BNE 
FTLX 


CMPB 
BNE 
SUCX 


CMPB 
BNE 
FTLX 


#"QD, SPDEV 
10$ 
ERRBDV 


S$SIZE, PRMLST 
#PRMLST, R4 
#ACPNAM,R3 
#T0.CTL!1,R2 


- QUEIO 

100$ 
#IE.UPN, SDSW 
20$ 

ERRNOD 
#IE.INS,$DSW 
30$ 

#IE. PRI, SDSW 
40$ 

ERRNAC 
ERRREQ 


#1S.SUC,$IOST 
110$ 
SUCCOM 


#IE.RSU,SIOST 
120$ 

ERRUSE 
#IE.DFU,SIOST 
130$ 

ERRNDS 

ERRINT 


ACP operation 


#"OD, SPDEV 
10s 
ERRBDV 


#PRMLST, R4 
#ACPNAM , R3 
#IO.CTL!I2,R2 


- QUEIO 
100$ 
#IE.UPN, SDSW 
140$ 

ERRNOD 


#IS.SUC,$IOST 
110$ 
REQOFF 


#I1E.FLN,SIOST 
120$ 
ERRFLN 


PROCESSORS 


specify size 


me we 


me me MO Ne TO NO TO MO Ne 


me me MO Ne 


me 


=e "OO Ne 
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Really QD:? 
If EQ yes 


Address of parameter 

Get address of parameter list 

Get address of ACP task name 

Set function code of ACP control 
and subfunction of START (1) 
Queue an I/O request to the ACP 
If CC successfully queued 

No pool? 

If NE no 


ACP not installed? 
If EQ yes 

Not an ACP? 

If NE no 


Catchall error message 
Success? 


If NE no 
Successful completion 


Already got an ACP or already started? 


If NE no 


3; Device full? 


™~e me =e 


™e we TA Me NO We We We 


we ™O we 


ue Ne 


If NE no 


Catchall error message 


Really QD:? 
If EQ yes 


Get address of parameter list 

Get address of ACP task name 

Set function code for ACP control 
and subfunction of STOP (2) 
Queue an I/O request to the ACP 
If CC successfully queued 

No pool? 

If NE no 


Success? 
If NE no 
Successful completion 


Already being off-lined? 
If NE no 
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140S: FTLX ERRNOL Not on line 


1208: CMPB #IE.NFW,SIOST ; Unit busy? 
BNE 130$ ; If NE no 
FTLX ERRBSY 
1308S: CMPB #IE.OFL,SIOST : Device not on line? 
BEQ 140$ ; If EQ yes 
FTLX ERRINT ; Catchall error message 
a 


**-,QUETO-Create and queue an I/O packet directly to an ACP 


This routine builds an I/O packet and queues it directly to an 

ACP bypassing the Executive QIO directive processing. The primary 

reason for doing this is the fact that under some circumstances 

the ACP cannot be reached by going through the driver, such as when the 
ACP has not been started. The parameter list is copied into the I/O packet 
without modification. Consequently, a buffer address cannot be passed 

aS a parameter; it must first be relocated and the address double word 
placed in the parameter list; this routine is not designed to do that. 


INPUTS: 
R4=Parameter list address 
R3=Address of ACP task name 
R2=I1/0 function code 
LUN 1 assigned to device associated with ACP 


OUTPUTS: 
If CC ACP requested and I/O complete 
SIOST is I/O status block containing return from ACP 
If CS ACP not requested 
SDSW is error status 
ITE.UPN - No dynamic memory for I/0 packet 
IE.INS - ACP not installed 
IE.PRI - Task not an ACP 


If entry at .QUEIO, all registers preserved 
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»~ENABL LSB 


-QUEIO: SWSTKS 40S Switch to system state 


7? 

CLR SIOST 37 Clear I/O status block 

CLR SIOST+2 77 Indicating I/O pending 

MOV SHEADR,R5 33; Get address of our task header 

MOV H.LUN(R5),R5 +; Get device UCB address 

MOV #IE.INS,SDSW 3; Assume task not found 

CALL SSRSTD 37 Search for task 

BCS 30S 33; If CS failure 

MOV #IE.PRI,SDSW :; Assume task not an ACP 

BIT #T3.ACP,T.ST3(RO) 3; Task an ACP? 

BEQ 30$ 7; If EQ no 

MOV RO, -(SP) 77 Save TCB address 

MOV R2,-(SP) 3 Save I/O function code 

MOV #IE.UPN,SDSW 3; Assume buffer allocation failure 

MOV #I.LGTH,R1 77 Length of I/O packet 

CALL SALOCB 77 Allocate buffer from pool 

BCS 308 3 If CS failure 

MOV (SP)+,R3 373 Restore R3 

MOV RO,-(SP) :3 Save address of I/O packet 

ASR Rl 77 Convert size in bytes to words 
10S: CLR (RO)+ 77. Zero I/O packet 

DEC Rl 33 Done? 

BNE 1605 :; If NE no 

MOV #SIOST,RO 7; Get I/O status block address 


D-31 
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CALL SRELOC 
MOV (SP)+,R0 
MOV #SIOST,1I.IOSB(RO 
MOV R1,1.IOSB+2 (RO) 
MOV R2,1.IOSB+4 (RO) 
MOV STKTCB,1.TCB(RO) 
MOVB #1,1.EFN(RO) 
MOVB #251.,1.PRI(RO) 
MOV R5,1.UCB(RO) 
MOV R3,1.FCN(RO) 
MOV RO,R1 
ADD #I.PRM,RO 
MOV #8.,R2 
20S: MOV (R4)+, (RO)+ 
DEC R2 
BNE 20$ 
MOV (SP)+,R0 
INC U. QOTRN(R5) 
CALL SEXRQP 
MOV STKTCB,RO 
INCB T. IOC (RO) 
CLR T. EFLG (RO) 
MOV #1S.SUC, SDSW 
30S: RETURN 
40S: TST SDSW 
SEC 
BLE 50$ 
WTSESS #1 
5058: RETURN 
.~DSABL LSB 
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SERRXT: 


10S: 


SSUCXT: 
20S: 


30S: 


Inputs: 
RO=Error table entry 


Outputs: 


Message 


. ENABL 


MOV 
MOV 
MOV 
QIOWSS 
BCC 


MOV 
QIOWsSs 
BCC 
IOT 
EXSTSS 


- DSABL 


- END 


**-SERRXT-Error exit 
**-SSUCXT-Success exit 


and task exit 


LSB 


(RO)+,R5 
(RO)+,R1 
(RO)+,R2 


#IO.WVB, #5, #5, rer 


10$ 


#ERRFTL+2, RO 
20$ 

(RO) +,R5 
(RO)+,R1 
(RO) +,R2 


#IO.WVB,#5,#5,,,/<R1,R2, 


30$ 
R5 
LSB 


SQDCON 


e 
tf 
° 
tf 
) 
e 
f 

e 
c 


we We MO Me Me MO We TH TO NO NO We TMH NO NO we VE we NH He NH NO Ne NE 


~~ me we ME 


me Ne NO Me NO 


f 


me "Oe 


me Me Ne te MO MH NE Me Ne Ne Ne Ne Ne Ne SO NOD Me Ne We NO MO NO 


<R1,R2, 


Relocate it 
Restore packet address 
:: Insert virtual address of status block 
Insert relocation bias and 
Offset of I/O status block 
Insert our TCB 
Insert event fiag number 
Insert priority 
Insert device UCB 
Insert function code 
Copy address of packet 
Point to parameter area 
Set parameter count 
Copy parameter list into packet 
Done? 
If NE no 
Get ACP TCB address 
Bump count of transactions queued to unit 
Queue I/0 packet to ACP by priority and 
ensure ACP is active 
Get our TCB address 
Bump our I/O count 
Clear event flag l 
Indicate success 
Return to task state 
QIO successful? 
Assume error 
If LE no 
Wait for I/O to finish 
Return to caller 


~ 


Get exit status 
Get address of error text 
Get size of text 
40> ; Write message 


Get address of fatal error message 
Join common code 

Get exit status 

Get address of final message 

Get size of message 

40> ; Write message 


Exit with status 


SACHCK routine, 5-2 
SACHKB routine, 5-2 
ACP, 
See Ancillary Control 
Processor 
ACP I/O function mask, 4-12 
Address doubleword, A-1l 
SALOCB routine, 5-3 
Alternate CLI support, 
UCB field, 4-25 
Ancillary Control Processor 
(ACP), D-1 
as extension of Executive, 
D-5 
as task, D-4 
attributes, D-4 
enabling and disabling 
capacity, D-5 
example, D-11l 
for class of devices, D-4 
I/O request flow, D-5 
processing, D-6 
role of, in I/O processing, 
2-3 
shareability, D-5 
type, D-2 to D-3 
SASUMR routine, 5-4, B-3 


Buffer, 
special, 6-9 


Cancel I/O entry point, 2-4 
DDT conditions, 4-10 
CDA, 
See Crash Dump Analyzer 
CINTS directive, 3-1 
CLI Parser Block (CPB), 
address in UCB, 4-25 
SCLINS routine, 5-5 
Conditional assembly symbol, 
LDSxx, 3-5 
Conditional routine, 5-1 
Control and status register 
(CSR) , 
address in SCB, 4-22 
Control I/O function mask, 
4-12 
Controller number, 2-14 
CPB, 
See CLI Parser Block 
Crash Dump Analyzer (CDA), 
debugging driver code, 3-20 


INDEX 


SCRAVL symbol, 
use of, in fault tracing, 


3-28 
CSR, 
See Control and status 
register 


Data base, driver, 
accessing shared, 2-9 
changing, 3-3 
controlling access to 

Shared, 2-10 

example, 6-2 to 6-4 

loadable, 

See Loadable data base 

overview, 3-5 

resident, 

See Resident data base 

Data structure, 2-7 
See also System data 

structure macro 
definition 

ACP interface, D-7 

DH11 terminal multiplexer, 

2-7 

figure, 2-19 

interaction with driver, 2-5 

interrelationship, 2-18 

macro definition, 

overview, 4-1 

RL11 disk, 2-8 

summary, 2-20 
DSSBUG label, 3-19 
DCB, 

See Device Control Block 
DDT, 

See Driver Dispatch Table 
SDEACB routine, 5-6 
Debugging, 

CDA, 3-20 

Executive stack and register 

dump routine, 3-16 

fault code, 3-26 

fault isolation, 

3-20 to 3-23 
fault tracing, 3-23 to 3-28 
Panic Dump routine, 

3-19 to 3-20 

XDT, 3-15, 3-17 to 3-18 
Debugging aid, 3-16 
SDEUMR routine, 5-7, B-3 
SDEVHD word, 2-19 

role of, in I/O data 

structure, 2-20 


Index-l 


Device Control Block (DCB), 
description, 4-7 
relationship of, with I/0 

control blocks, 2-6 
required field, 3-6 
role of, in I/O data 

structure, 2-20 
with ACP, D-9 

Device Control Block (DCB) 

field, 
D.DSP, 3-6, 
D.LNK, 3-6, 
D.MSK, 3-6, 
D.NAM, 3-6, 
D.PCB, 3-6, 
D.UCB, 3-6, 
D.UCBL, 3-6, 
D.UNIT, 3-6, 4-9 

Device interrupt entry point, 

2-4 

Device interrupt vector, 
definition, 2-10 

Device time-out entry point, 

2-4 
DDT conditions, 4-11 
Directive Parameter Block 
(DPB), 2-5 
description, 4-6 
source of I/O packet 
information, 2-9 


4-33 


DPB, 


INDEX 


See Directive Parameter Block 


Driver, 
changing code, 
debugging, 
See Debugging 
function, 1-2 
loadable, 
See Loadable driver 
multicontroller, 2-10 
Non-MASSBUS NPR, B-1l 
postinitiation service, 2-11 
preinitiation processing of, 
2-11 

process-like characteristic, 
2-13 

property, 1-2 

rebuilding and 
reincorporating, after 
debugging, 3-29 to 3-30 

resident, 

See Resident driver 
role of, in RSX-11M, 2-5 
Software Performance Report 

(SPR) support, 3-4 
SYSGEN support, 3-l 
pe, 11 
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Driver code, 
changing, 
example, 6-4 to 6-9 
overview, 3-4 

Driver data base, 

See Data base, driver 

Driver Dispatch Table (DDT), 
address, 3-5 
role of, in I/O data 

structure, 2-20 

Driver entry point, 
cancel I/O, 2-4, 4-10 
device interrupt;2-4 


3-3 


device time-out, 2-4, 
4-11 

I/O initiator, 2-4, 2-12, 
4-10 


power failure, 2-4, 
Driver global symbol, 

SxxINP, 3-5 

$xxINT, 3-5 

SxxOUT, 3-5 

SxxTBL, 3-5 
DROQOIO module, 

service performed in 

processing QIO, 

SDVMSG routine, 5-8 


4-11 


2-11 


Error logging, 
modifying driver to 
incorporate, 3-5 
SCB field, 4-20 
UCB field, 4-24 to 4-25 
Executive Crash Dump routine, 
3-20 
Executive Debugging Tool 
(XDT), 
debugging driver code, 
3-17 to 3-18 
ODT features and commands 
not included, 3-17 
Executive service, 
driver processing, 2-10 
postinitiation, 2-il 
preinitiation, 2-11 
Executive service calls, 
5-1 to 5-28 
Executive stack and register 
dump routine, 3-17 
debugging driver code, 
3-16 
use of, 
3-25 


in fault tracing, 


Index-2 


INDEX 


FI1ACP, 
role of, in I/O data 
structure, 2-19 
Fault code, 3-26 
Fault isolation, 3-20 to 3-23 
Fault tracing, 3-23 to 3-24 
after unintended loop, 3-28 
Executive stack and register 
dump, 3-25 to 3-27 
hints, 3-28 to 3-29 
in new driver, 3-28 
when processor halts without 
display, 3-27 
FCP, 
See File Control Processor 
FCS, 
See File Control Services 
File Control Block (FCB), 
role of, in I/O data 
Structure, 2-20 
File Control Processor (FCP), 
role of, in I/O data 
structure, 2-19 
File Control Services (FCS), 
position of, in I/0 
hierarchy, 2-2 
Fork block, 
storage words in SCB, 4-23 
Fork level processing, 2-15 
Fork list, 2-9 
Fork process, 2-9 
creating with SFORK, 2-12 
SFORK routine, 5-10 
accesSing shared driver data 
base, 2-10 
initiating fork process, 2-9 
SFORK1 routine, 5-11 
Function mask word, 
See I/O function mask 


Global label, 
SUSRTB, 3-13 
SxxDAT, 3-9 
$xxEND, 3-9 
SxxTBL, 4-10 
SGTBYT routine, 5-12 
SGTPKT routine, 2-12, 5-13 
in driver processing, 2-17 
use of, with ACP, D-6 
SGTWRD routine, 5-14 
conditional assembly, 5-1 
inclusion of, by SYSGEN, 3-2 


SHEADR pointer, 
use of, in fault tracing, 


Index-3 


SHEADR pointer (Cont.) 
3-24 


ICB, 
See Interrupt Control Block 
Interrupt Control Block (ICB), 
3-2, 4-35 
Interrupt entry point, 
address, 3-5 
Interrupt processing, 

fork level, 2-9, 2-15 

priority 7, 2-14 

priority of interrupting 
source, 2-14 

INTSV$ macro, 
description, 4-35 
format, 4-35 
SINTSV routine, 2-12, 5-15 
calling with INTSVS macro, 
4-35 

processing at priority of 
interrupting source, 
2-15 

SINTXT routine, 5-16 

I/O control blocks, 
interrelationship, 2-6 

I/O data structure, 

See also System data 
Structure macro 
definition 

See Data structure 

I/O driver, 
See Driver 
I/O function mask, 

ACP, 4-12 

control, 4-12 

creating, 4-13 

legal, 4-12 

no-op, 4-12 

values for disk drive, 4-16 

values for magtape drive, 
4-17 

values for standard 
functions, 4-15 

values for unit record 
device, 4-18 

I/O hierarchy, 2-1 
I/O initiator entry point, 
2-4, 2-12 
DDT conditions, 4-10 
I/O packet, 2-8 

description, 4-2 

format, 4-3 

pointer in SCB, 4-21 

with ACP, D-7 


TSN wanerlbak Fi 
A/V paenete Lb 


I.AST, 4-5 


I/O packet field (Cont.)} 
I.EFN, 4-3 
I.FCN, 4-4 
I.IOSB, 4-4 
I.LNK, 4 
I.PRI, 4 
I.PRM, 4-~ 
I.TCB, 4 
I.UCB, 4-4 
I/O philosophy, 2-1 
I/O processing, 
ACP, 2-3 
QIO directive, 2-3 
I/O queue, 2-9 
I/O request, 
flow, 2-16 to 2-17 
SIOALT routine, 2-13, 5-17 
SIODON routine, 2-13, 5-17 
SIOFIN routine, 5-18 
use of, by ACP, D-7 
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LDSxx symbol, 3-5 
required by INTSVS macro, 
4-35 
Legal I/O function mask, 4-12 
LOA command, 4-35 
action if UC.PWF set, 2-4 
effect of, when loading 
driver, 3-8 
loading driver, 3-2, 3-12 
Loadable data base, 
advantage, 3-8 
assembling, 3-9 
characteristics, 3-8 
Loadable driver, 
assembling, 3-9 
benefit, 1-1 
combination with data base, 
3-1 
debugging, 3-8 
definition, 1-1 
incorporating, with data 


base, 3-8 

linking, with loadable data 
base, 3-3 

linking, with resident data 
base, 3-3 

loading, into memory, 3-2, 
3-12 


rebuilding and 
reincorporating, after 
debugging, 3-30 
removing, from memory, 3-2 
task-building, 
Mapped system, 3-10 
unmapped system, 3-11 


INDEX 


Loadable driver (Cont.) 
task-building, with resident 
data base, 3-12 
Logical unit number (LUN), 
2-19 
preinitiation processing of, 
2-11 
Logical Unit Table (LUT), 2-19 
LUN, 
See Logical unit number 


LUT, 


See Logical Unit Table 


Mapping register assignment 
block, 
allocating, B-2 
figure, B-3 
SMPUB1 routine, 5-20, B-3 
use of, to obtain UMRs, B-l 
SMPUBM routine, 5-19, B-3 
use of, to obtain UMRs, B-1l 
Multicontroller driver, 2-10 
conditional code 
description, 4-33 
conditional code example, 
4-34 


No-op I/O function mask, 4-12 
NPR device driver, B-1l 

use of SCB field S.MPR, 4-23 
NSSUMR symbol, B-4 


Panic Dump routine, 3-19 
sample output, 3-20 

Partition Control Block (PCB), 
address in DCB, 4-14 

SPKAVL symbol, 
use of, in fault tracing, 

3-28 

Power failure entry point, 2-4 
DDT cenditions, 4-11 

Process, 
state, 2-10 

Programming convention, 2-13 

Programming protocol, 2-14 
Summary, 2-16 

SPTBYT routine, 5-21 

SPTWRD routine, 5-22 
conditional assembly, 5-1 
inclusion of, by SYSGEN, 3-2 


Index-4 


INDEX 


SQINSP routine, 5-23 
QIO directive, 
position of, in I/O 
hierarchy, 2-2 
preinitiation processing of, 
2-11 
role of, in I/O processing, 
2-3 
QITO Directive Parameter Block, 
4-6 
SORMVF routine, 5-24 
use of, with ACP, D-6 


Record Management Services 
(RMS) , 
position of, in I/O 
hierarchy, 2-2 
RED command, 2-6 
SRELOC routine, 5-25 
Resident data base, 
assembling, 3-12 
example, 6-1 
Resident driver, 
assembling, 3-13 
combination with data base, 
3-1 
definition, 1-1 
example, 6-1 
incorporating, 3-13 
linking data base, 3-3 
rebuilding and 
reincorporating, after 
debugging, 3-29 
task-building, 3-14 


RMS, 
See Record Management 
Services 
SCB, 


See Status Control Block 
Special buffer handling, 6-9 
example, 6-9 to 6-11 
SST fault, 
abnormal, 3-27 
internal, 3-26 
Stack structure, 
abnormal SST fault, 3-27 
data items on stack, 3-28 
internal SST fault, 3-26 
Status Control Block (SCB), 
description, 4-19 
relationship of, with I/0 
control blocks, 2-6 
required field, 3-7 
role of, in I/O data 


Index-5 


Status Control Block (SCB) 
(Cont.) 
structure, 2-20 
Status Control Block (SCB) 
field, 
S.BMSK, 4-20 
S.BMSV, 4-20 
S.CON, 3-7, 4-22 
S.CSR, 3-7, 4-22 
S.CTM, 4-21 
S.FRK, 3-7, 4-23 
S.ITM, 3-7, 4-21 to 4-22 
S.LHD, 3-7 to 3-8, 4-2, 4-29 
S.MPR, 3-7, 4-23, B-l to B-2 
S.PKT, 4-23 
S.PRI, 3-7, 4-21 
S.RCNT, 4-20 
S.ROFF, 4-20 
S.STS, 3-7, 4-22 
S.VCT, 3-7, 4-21 
SSTKDP pointer, 
use of, in fault tracing, 
3-23 
SSTMAP routine, 5-26, 
B-2 to B-3 
use of, to obtain UMRs, B-1 
SSTMP1 routine, 5-27, 
B-2 to B-3 
use of, to obtain UMRs, B-l 
SSTPCT routine, 
use of, by ACP, D-7 
SSWSTK routine, 5-28 
Symbolic offsets, 
for system data structures, 
C-1 
SYSCM, 
See System common 
SYSTB file, 
creation of, by SYSGEN, 3-1 
System common (SYSCM), 
use of, in fault isolation, 
3-23 
System common (SYSCM) pointer, 
SCRAVL, 3-28 
SHEADR, 3-24, 3-27 
SPKAVL, 3-28 
SSTKDP, 3-23, 3-27 
STKTCB, 3-24, 3-27 
System data structure macro 
definition, C-l 
ABODFS, C-3 
CLKDFS, C-4 


DCBDFS, C-6 
EPKDFS, C-7 
FlIDFS, C-14 
HDRDFS$, C-19 


HWDDF$, C-21 
ITBDFS, C-24 
LCBDF$, C-25 


INDEX 


System data structure macro 
(Cont.) 
MTADFS, C-26 
PCBDFS, C-30 
PKTDFS, C-32 
SCBDFS$, C-37 
TCBDFS, C-39 
UCBDFS, C~-42 
System generation, 
incorporating driver, 3-l 
System state register 
convention, 5-1 


Task header, 
mapped system, 3-25 
role of, in I/O data 
structure, 2-19 
unmapped system, 3-24 
STKTCB pointer, 
use of, in fault tracing, 
3-24 
Transfer function, 
processing, 4-13 
TTDRV, 
LOA special case, 3-5 


UCB, 
See Unit Control Block 
UNIBUS Mapping Register, 
Static allocation of, during 
system generation, B-4 
Unit Control Block (UCB), 
description, 4-23 
figure, 4-26 
negative offset, 4-9 
relationship of, with I/0 
control blocks, 2-6 
required field, 3-7 
role of, in I/O data 
structure, 2-20 
with ACP, D-9 


Unit Control Block (UCB) field, 


U.ATT,- 3=7;. 4-31 
U.BUF, 4-31 
U.CLI, 4-25 
U.CNT, 4-32, B-l 


U.CTL, 2-9, 3-7, 4-10, 4-27 
U.CWl1, 3-7, 4-29 
U.CW2, 3-7, 4-30 
U.CW3, 3-7, 4-30 
U.CW4, 3-7, 4-31 
U.DCB, 3-6 to 3-8, 4-9, 4-27 
U.ERHC, 4-25 
U.ERHL, 4-24 
U.ERSC, 4-24 
U.ERSL, 4-24 
U.IOC, 4-24 
U.LUIC, 4+25 
U.MUP, 4-25 
U.OWN, 4-27 
U.RED, 3-7 to 3-8, 4-27 
U.SCB, 3-7 to 3-8, 4-31 
U.ST2, 3-7, 4-29 
U.STS, 3-7, 4-28 
U.UNIT, 3-7, 4-29 
UNL command, 
unloading driver, 3-2 
USRTB file, 
content, 3-12 
SUSRTB label, 3-13 


Volume Control Block (VCB), 
role of, in I/O data 
Structure, 2-20 


Window Block (WB), 
role of, in I/O data 
Structure, 2-19 to 2-20 


XDT, 
See Executive Debugging Tool 
$xxDAT label, 3-9 
SxxEND label, 3-9 
SxxINP symbol, 3-5 
SxxINT symbol, 3-5 
$xxOUT symbol, 3-5 
SxxTBL label, 
on driver dispatch table 
(DDT), 4-10 
$xxTBL symbol, 3-5 
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